OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalruleml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: LegalRuleML-TC-2012-07-11v1.doc (97K) Minutes


Hi,

I just read the minutes. 

>Adrian propose three kind of attributes like in Reaction Rule: key, iri, node with different meaning. This for taking also in consideration the >computational side effect on the Xpaht manipulation.

My remarks were not about computational side effects and XPath manipulation. My issues are:

1. The semantics of xs:key-xs:keyref and node are different. To distinguish both RuleML 1.0 and Reaction RuleML 1.0 replaced the old <oid> element which was used for both. The attribute “node” replaced the <oid> element in RuleML 1.0 and is intended for a RDF like “about” description. “xs:key-keyref” attributes, as used in Reaction RuleML, is used for modularization of a distributed knowledge base in order to refer between corresponding elements in a modular knowledge base. While “node” does not follow a unique name assumption, xs:key ensures a unique identifier and additionally can validate the correctness of references using a standard XML validator. The semantics of both should not be mixed as this would violate referential transparency.  
2. xs:key as well as other XML identifier (id-idref) only work on one XML instance, but not on multiple different XML instance. Reaction RuleML uses XIncludes for including distributed instances into one XML instance. 
3. If we additionally introduce XSLT as a kind of “pre-processor” before Legal RuleML documents can be processed/validated by standard XML validators, we introduce an additional mandatory tool layer - an XSLT transformation pre-processor, which has many drawbacks.

Cheers,

Adrian


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]