'Re: [xml-dev] A more fundamental concept than functions: units of code that self-select'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-dev
Subject:    Re: [xml-dev] A more fundamental concept than functions: units of  code that self-select
From:       Olivier Rossel <olivier.rossel () gmail ! com>
Date:       2010-05-18 12:16:27
Message-ID: AANLkTinil59ubc9PFl89B3kVk0ZhNIcAPTjF8hPRDrwG () mail ! gmail ! com
[Download RAW message or body]

without going into the RDF vs XML debate, i must admit the capability
of a rule engine
to enhance its original data set with business rules has definitely
made me a description-logic and inference engine fanatic.

On Tue, May 18, 2010 at 1:26 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Olivier,
> 
> I was hoping someone would bring up rule engines. That is very exciting about a \
> rule adding more data to the input, thus triggering other rules to fire. Wow! 
> /Roger
> 
> -----Original Message-----
> From: Olivier Rossel [mailto:olivier.rossel@gmail.com]
> Sent: Tuesday, May 18, 2010 4:28 AM
> To: Hermann Stamm-Wilbrandt
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] A more fundamental concept than functions: units of code \
> that self-select 
> self-selecting units of code are the fundament of all (forward) rules engines.
> such as drools, euler, cwm, fuxi, etc.
> 
> the differences between these rules engines and xslt is the concept of
> working memory.
> the working memory is the set of data that are processed by the rule
> engine to decide which
> rules to trigger.
> 
> in xslt, the working memory could be seen as the input document(s).
> with the limitation
> that the running stylesheet cannot alter its working memory (i.e the
> input document(s)).
> 
> on the contrary, in rules engines, the working memory is accessible to
> the rules also in write mode.
> so rules can add data to the working memory, and these data will
> trigger other rules that add
> other data to the working memory, and so on.
> 
> 
> On Tue, May 18, 2010 at 10:05 AM, Hermann Stamm-Wilbrandt
> <STAMMW@de.ibm.com> wrote:
> > > Are there other programming languages that support self-selecting units
> > of code?
> > David already pointed to C++ and Java.
> > 
> > Add perl, awk and even sed to that list (/regexp/ selectors).
> > 
> > 
> > Mit besten Gruessen / Best wishes,
> > 
> > Hermann Stamm-Wilbrandt
> > Developer, XML Compiler, L3
> > WebSphere DataPower SOA Appliances
> > ----------------------------------------------------------------------
> > IBM Deutschland Research & Development GmbH
> > Vorsitzender des Aufsichtsrats: Martin Jetter
> > Geschaeftsfuehrung: Dirk Wittkopp
> > Sitz der Gesellschaft: Boeblingen
> > Registergericht: Amtsgericht Stuttgart, HRB 243294
> > 
> > 
> > 
> > "Costello, Roger
> > L."
> > <costello@mitre.o                                          To
> > rg>                       "xml-dev@lists.xml.org"
> > <xml-dev@lists.xml.org>
> > 05/18/2010 12:27                                           cc
> > AM
> > Subject
> > [xml-dev] A more fundamental
> > concept than functions: units of
> > code that self-select
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Hi Folks,
> > 
> > XSLT has xsl:template and xsl:function. On the surface they appear to be
> > the same: you invoke a template rule using xsl:apply-templates and you
> > invoke a function by dereferencing its name; you can pass parameters to
> > both; both return values.
> > 
> > Clearly the idea of "function" is a fundamental concept in Computer
> > Science.
> > 
> > It occurs to me that the functionality provided by template rules represent
> > an even more fundamental concept. In fact, functions are merely a subset of
> > the functionality provided by template rules.
> > 
> > Allow me to explain.
> > 
> > Consider these three template rules:
> > 
> > <xsl:template match="Book[Publisher lt 1970]">
> > 
> > <xsl:template match="Book[Publisher eq 1970]">
> > 
> > <xsl:template match="Book[Publisher gt 1970]">
> > 
> > Suppose that Book is the context node and it has a Publisher child element
> > with value 1970. With this apply-templates:
> > 
> > <xsl:apply-templates select="." />
> > 
> > the second xsl:template rule will fire. Of the three template rules, the
> > second one self-selected ("I meet the requisite conditions; I will now
> > activate myself").
> > 
> > Template rules have the ability to self-select. Functions never
> > self-select. They must always be explicitly called out.
> > 
> > Template rules can also be explicitly called out. Consider these revised
> > templates:
> > 
> > <xsl:template match="*" mode="pre-1970">
> > <param name="Book" />
> > 
> > <xsl:template match="*" mode="eq-1970>
> > <param name="Book" />
> > 
> > <xsl:template match="*" mode="post-1970">
> > <param name="Book" />
> > 
> > The second template can be explicitly called out:
> > 
> > <xsl:template select="." mode="eq="1970">
> > <xsl:with-param name="Book" select="." />
> > 
> > Each template rule is "named" using mode. Effectively the mode is used as
> > the name of the template rule.
> > 
> > So template rules are units of code that can be either explicitly called
> > out, or can self-select.
> > 
> > Functions are units of code that can only be explicitly called out.
> > 
> > The ability to create self-selecting units of code is very powerful. It
> > resounds of decentralization, local-control, Complex Systems. Wow!
> > 
> > Are there other programming languages that support self-selecting units of
> > code?
> > 
> > Do you agree that self-selecting units of code represents a more
> > fundamental concept than functions?
> > 
> > /Roger
> > 
> > 
> > 
> > _______________________________________________________________________
> > 
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> > 
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > 
> > 
> > 
> > 
> > _______________________________________________________________________
> > 
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> > 
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > 
> > 
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 
> 

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic