[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Specification of a transform.


Subject: Re: [xsl] Specification of a transform.
From: Wolfgang Laun <wolfgang.laun@xxxxxxxxx>
Date: Tue, 10 Sep 2013 10:09:33 +0200

There is a substantial subset among the "expressive power" between
XPath and the language of Rule Based Systems, especially those that
are embedded in an object-oriented environment. "Constraint
programming" would be the common denominator. Thus, an XSLT template
works quite similar to a rule (although rules appear to be easier to
write for data that is organized like a relational DB than that in a
deep hierarchy).

Thus, rules can express the data analysis side of a transformation
very well. One system I know very well (Drools) also features a
technique for implementing a Domain Specific Language of your design,
with a translator to the native rule language.

Production Rule Systems let you also specify actions, to be executed
for each match on the data, and this would normally be used to define
the synthesis part, but since this is procedural it does not map so
well to the functional approach, especially when you look at the way a
"pull" transformation is designed.

Cheers
Wolfgang


On 10/09/2013, davep <davep@xxxxxxxxxxxxx> wrote:
> On 10/09/13 03:19, Paul Tyson wrote:
>> On Mon, 2013-09-09 at 08:42 +0100, davep wrote:
>>> Given schema A as input XML. Schema B as XML output.
>>>     Assume no hierarchical simple relationship.
>>>     Assume mapping of values needed from input values to output values.
>>>     Assume literals are needed.
>>> How do (might) you specify the required transform?
>>
>> I have been struggling with a problem I think is similar to the one you
>> have posed, except that it involves RDF graphs instead of XML schemas
>> and instances. But since a tree is a specialized graph, the techniques
>> for graphs should work for XML.
>>
>> I was led to a solution whereby I specified the expected outcomes in a
>> generic rule language. I selected ISO Common Logic. Other options would
>> have been RuleML or RIF.
>
> http://ruleml.org/rif/rulelog/spec/Rulelog.html
> and http://ruleml.org/papers/ for associated papers.
>
> Does this seem like providing a formalism for plain English?
> See http://ruleml.org/papers/tutorial-ruleml-20050513.html
>
>
>>
>> The rules are expressed as quantified logical formulas, mainly of the
>> form "for all things like this in the world of A, there must exist
>> things like that in the world of B". Or conversely "If something like
>> this exists in B, then something like that must exist in A."
>
> Not unlike Schematron.
>
>>
>> I'm sure there must be a large literature out there that hasn't filtered
>> down to general industrial usage--particularly in XML practice--, which
>> would specify the types of rules and transformations that are amenable
>> to this approach. I'm also pretty sure there are limitations, in that
>> some types of transformations cannot be specified in this manner. But I
>> believe there is a large subset of practical problems that can be
>> tackled this way.
>
> Lots of unknowns.
>
>>
>> Rules specified in a generic language can be put to different purposes:
>> for generating test cases; for generating code for certain
>> well-understood transformations; for generating queries over the
>> datasets to check for rule violations; and for generating human-readable
>> documentation.
>>
>> I have not had the opportunity to do much of this in XML, although I
>> developed something similar using schematron for an XML validation
>> problem.
>>
>> Regards,
>> --Paul
>
> Thanks Paul.
>
>
>
>
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk


Current Thread
Keywords