[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML documents get richer and richer the more XSLT rulestha

• From: Jonas Mellin <jonas.mellin@his.se>
• To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
• Date: Wed, 19 May 2010 09:24:01 +0200

Costello, Roger L. wrote:
> Olivier Rossel wrote:
>
>   
>> 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.
>>     
>
> Fascinating!
>   
Well, depends... In the beginning of the 1990s, active databases were
not considered useful for typical database applications due to the
problems of rule-termination, confluence, + proving other properties of
complex rule sets. Essentially, arbitrary rule sets do not scale well
since it become exponetially more combinations to cover. Fortunately,
templates, the equivalent component for rule sets in XSLT, emphasize
limitation of scope (e.g., templates are applied to a subset of elements
in a tree structure), avoids concurrent evaluation and triggeriring of
evaluation (although I am unsure of the specification forbids concurrent
evaluation and triggering of templates) and, therefore, they do not
suffer as much from the scalability problem as arbitrary rules in active
databases (relational or object-oriented). However, even though the
situation is better in evaluation of XSLT templates compared to
evaluation of active database rule sets, it may be difficult to ensure
correctness and other properties of the evaluation. In addition, testing
can become a nightmare.

So, "fascinating" for small problems, but larger problems is still
problematic. A skilled designer is typically required to improve the
probability of building solutions that are correct, flexible in the
sense that the functionality can be extended, dynamic in the sense that
many configurations can be handled, reusable in similar applications,
composable in the sense that different template sets can be mixed,
testable in the sense that selected test cases are likely to demonstrate
errors etc.

BTW, are there any automatic analysis tools for XSLT templates?

/Jonas
> I decided to create an example to illustrate this. Would someone be willing to create an XSLT implementation?
>
> This is the input document to an XSLT program:
>
> <Gun>
>      <serial>ABCD</serial>
> </Gun>
>
> The XSLT program contains a rule for the Gun serial element. The rule fires. The rule maps serial numbers to person names. Thus, the rule adds person information to the XML document. After the rule finishes, this is the XML document:
>
> <GunLicense>
>     <registeredGun>
>          <Gun>
>               <serial>ABCD</serial>
>          </Gun>
>     </registeredGun>
>     <holder>
>          <Person>
>               <name>Fred Blogs</name>
>          </Person>
>     </holder>
> </GunLicense>
>
> The XSLT program contains a rule for the Person name element. The rule fires. The rule maps names to drivers license numbers. The rule adds drivers license information to the XML document. After the rule finishes, this is the XML document: 
>
> <GunLicense>
>     <registeredGun>
>          <Gun>
>               <serial>ABCD</serial>
>          </Gun>
>     </registeredGun>
>     <holder>
>          <Person>
>               <name>Fred Blogs</name>
>               <driversLicenseNumber>ZXYZXY</driversLicenseNumber>
>          </Person>
>     </holder>
> </GunLicense>
>
> The XSLT program contains a rule for the driversLicenseNumber element. The rule has information about a speeder that the police just pulled over, and a recent robbery where the robber dropped the gun. The driver's license and Gun serial number match the values in the XML document. The rule knows that only one gun can have any given serial number, and only one person can have any given driver's license number, so the rule outputs this as the result XML document:
>
> <Alert>
>    The speeder is the person who committed the recent robbery!
> </Alert>
>
> Recap: the initial XML input into the XSLT program is small. A rule for the Gun serial element fires and adds Person data to the XML input document. This causes a rule for the Person name element to fire, which adds driver's license data to the XML input document. This causes a rule for driver's license element to fire, which recognizes that the speeder is the robber; the rule outputs an XML document that alerts the police about the person he has pulled over.
>
> The XSLT rules add data to the XML input document! The XML document gets richer and richer the more rules that process it!
>
> Would someone be willing to write an XSLT program that implements this? 
>
> Thanks Olivier!
>
> /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
>
>   


-- 
Carpe Diem!
===
Jonas Mellin, Assistant Professor in Computer Science
School of Humanities and Informatics, Building E-2
University of Skövde, P.O. Box 408, SE-541 28 Skövde, Sweden
Phone: +46 500 448321, Fax: +46 500 448399
PGP Public Key: http://www.his.se/PageFiles/19377/Jonas_Mellin.asc
Email: jonas.mellin@his.se, URL: http://www.his.se/melj, 

----BEGIN GEEK CODE BLOCK----
GCS d s a+ C++ UL++ US++ P++ L++ E++ W++ N+ o K- w++ O- M V-- 
PS- PE+ Y+ PGP t+ 5 X R* tv- b++ DI+ D+ G+ y++++ e++++ h--- r+++
----END GEEK CODE BLOCK----

OpenPGP digital signature

• References:
  • XML documents get richer and richer the more XSLT rules thatprocess it
    • From: "Costello, Roger L." <costello@mitre.org>