See Extending XML Languages via XML Transformation for background information.
Presented here is an illustration of how simple XML transformations may be used to customize succinct XML languages to fit specialized user communities. This example is from the Advanced Logistics (ALP) or COUGAAR (open software version) domain; it illustrates how an explicit and very general XML PlugIn Contract language can be generated via XML transformation from simpler "short-hand" languages. Specifically short-hand languages which are rule-driven and can be customized around usage-patterns and context associated with user communities (eg. ALP PlugIn developers).
With the approach here, Logic Providers (LPs) implement single-rule transforms of XML "rules". Multiple rules may be chained together to specify a complete XML document transform. Here are a few conventions on intepreting this short-hand language.
The "short-hand" LanguageThis short-hand language is analogous in several respects to declarative logic programming languages (such as pure prolog) etc. More to the point, it also shares commonality with IBM's CommonRules -- which is an XML-based ecommerce business rules language.
Advantages/ FeaturesRule-driven interpretation enables customized "short-hand" languages to be developed per different user community. Making possible:
Different nomenclature
Different language/expression abstractions
Presented here is simple example for illustration only. There are other possible language designs with different feature sets. The attraction of a "plugin based" transformer model (via Logic Providers) is that this can be a scalable approach.
The following are four sample Plugin Contract predicates taken from the ALP domain. They are very similar with a great deal of syntactic redundacy as well as fairly verbose. The Plugin Contract language is powerful in its generality. The price of this flexibility is the need to be explicit and unambiguous across all usage contexts.
For users working in smaller defined domains, trading-off language flexibility with succinctness and context sensitivity makes sense. The illustration here is to contemplate a transformation from a rule-based "short-cut" language to an ALP PlugIn Contract language.
<and>
<isTask/>
<getVerb equals="RFDReRoute"/>
<getPrepositionalPhrases>
<exists>
<and>
<isPrepositionalPhrase></isPrepositionalPhrase>
<getPreposition>
<equals-Object>Constants.Preposition.FOR</equals-Object>
</getPreposition>
<getIndirectObject>
<isOrganization/>
</getIndirectObject>
</and>
</exists>
</getPrepositionalPhrases>
</and>
|
<and>
<isTask/>
<getVerb>
<equals-Object>Constants.Verb.ReportForDuty</equals-Object>
</getVerb>
<getPrepositionalPhrases>
<exists>
<and>
<isPrepositionalPhrase></isPrepositionalPhrase>
<getPreposition>
<equals-Object>Constants.Preposition.FOR</equals-Object>
</getPreposition>
<getIndirectObject>
<isOrganization/>
</getIndirectObject>
</and>
</exists>
</getPrepositionalPhrases>
</and>
|
<and>
<isTask/>
<getVerb>
<equals-Object>Constants.Verb.REPORTFORSERVICE</equals-Object>
</getVerb>
<getWorkflow>
<isNotNull/>
</getWorkflow>
<getPlanElement>
<isNotNull/>
</getPlanElement>
</and>
|
<and>
<isPlanElement/>
<and>
<getTask>
<or>
<getVerb>
<equals-Object>Constants.Verb.REPORTFORDUTY</equals-Object>
</getVerb>
<getVerb>
<equals-Object>RFDReRoute</equals-Object>
</getVerb>
</or>
</getTask>
<isAssetTransfer/>
</and>
</and>
|
Given the above contracts, consider the XML rules below. In this example, the top-level rule "selectAllMyTasks" is custom-designed: it returns a specialized set of tasks (analogous to the above plugin contract examples). To do so it relies on 2 types of rules: a. Rules to "find tasks in the logplan" and b. rules to find and test values within Tasks.
Its worth noting that the rules below encapsulate 3 different "locations" where Tasks can be found in the ALP LogPlan ("first class" objects, parent tasks to workflows, and workflow children tasks). It also encapsulates 2 access patterns (get task by-verb and by-direct-object). Rules can be designed to reflect the usage patterns and context of particular user communities.
<!--
==============================================================================
Personal Rule (Custom) to find all MY Tasks.
==============================================================================
-->
<!--
GET all tasks THEN apply selection filtering. This is unnecessarily
general for the ALP domain where specific types of Tasks
are known to be located in particular niches and not others.
-->
<selectAllMyTasks>
<!-- Add selection criteria by "mixing-in" into element/rule attributes
Applied to rule set generated by getAllTasks
-->
<getAllTasks>
<!-- implicit AND of selection criteria -->
<verb>RFDReRoute</verb>
<verb>Contants.Verb.ReportForDuty</verb>
<indirectObject>Organization</indirectObject>
</getAllTasks>
</selectAllMyTasks>
<!--
==============================================================================
Intra-Task Navigation rules
==============================================================================
-->
<verb>
<and>
<isTask/>
<getVerb/>
</and>
</verb>
<indirectObject>
<and>
<isTask/>
<getPrepositionalPhrases>
<exists>
<and>
<isPrepositionalPhrase/>
<getPreposition>
<equals-Object>Constants.Preposition.FOR</equals-Object>
<getIndirectObject/>
</and>
</exists>
</getPrepositionalPhrases>
</and>
</indirectObject>
<!--
==============================================================================
LogPlan Navigation rules to find Tasks
==============================================================================
-->
<!-- Canned rule to find all Tasks
ala Logic Programming rules, Failure leads to backtrack and re-try all
getTask rules. Effect is to obtain all tasks in all niches in LogPlan
where tasks can reside.
Once got all tasks, apply selection filtering. In
ALP domain this algorithm is too broad. Often specific types of Tasks
are located in particular niches and not others.
Implicitly accumulates state (LogPlan references) unless reset.
-->
<getAllTasks>
<!-- accumulate all the Tasks in all the niches in LogPlan.
do in sequence.
-->
<do>
<reset/>
<getTask>
</getTask>
<Fail/>
</do>
</getAllTasks>
<!-- Tasks may or may not be "first class Container objects". There are couple of places
too look for 'em in LogPlan
-->
<getTask>
<isTask/>
</getTask>
<getTask>
<getWorkflow>
<getParentTask/>
</getWorkFlow>
</getTask>
<getTask>
<getWorkflow>
<getTasks>
<exists>
<isTask/>
</exists>
</getTasks>
</getWorkFlow>
</getTask>
|
An important point of this illustration is that through XML transformation, custom short-hand languages can be designed for specific user communities. For example, there can be a number of different short hand languages, each supporting a different manner of use by different users, all of which are transformed into a common Plugin Contract language.
An additional point is that rule-interpreted XML languages can pattern such "short-hand" language designs. They serve by this example to maximize opportunities to customize the language, as well as to increase their transparency.
Customized rule-interpreted languages means that the language can be expanded by adding new rules which build upon existing rules. Transparency here means that because the rules specify all relevant domain information (eg. Navigation and Value extraction used) these rules are self-contained w/respect to the domain information they use. Hence as user's needs/ expectations change, rules can be modified instead of modifying the base language and forcing all users in all communities to modify their languages.
And finally, implied though-out is that rule-interpreted "short-cut" XML languages can be implemented via a Logic Provider XML Transformation model as described here.
Contact Nathan Combs. Last modified 13 June 2000 © BBNT Solutions LLC