[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Revised Section 5
Other new things in the commits* The build script has been significantly enhanced in order to test the schemas more than before, especially in regard to preserving the abstract syntax (ie. the RDF) when performing transformations, such as converting between compact and normalized serializations, on instances (our fixed examples and randomly generated instances from the schemas). It now takes over an hour for the build to run, what with all the testing. * In addition to parsing to the RDF form that terminates at the templates, I have applied the same conversion principles to the template contents, to ensure that the information within the templates is also preserved when the transformations are carried out. * metamodel RDFS documents were updated to include the new LegalReference(s) and Source(s) entities. I have not yet updated the diagrams.
Tara 5 LegalRuleML XML Design Principles (non-normative)The concrete XML-based syntax for LegalRuleML was designed based on the principles in Sec. 2.3, as well as certain design principles that are specific to XML-based syntaxes (section 5.1) and additional design principles (sections 5.2-5.9) that are domain-specific. In particular, many of the XML conventions developed in RuleML are adopted in LegalRuleML, providing common principles for the merged language hierarchy. All statements herein about the RuleML syntax are in reference to the elements in the RuleML namespace that are allowed to be embedded within LegalRuleML documents; as such, these are restrictions from the more general RuleML syntax as well as extensions in regard to child elements in the LegalRuleML namespace.
5.1 XML Elements vs. AttributesA common design decision for XML-based languages is whether to use an XML element or an attribute to represent a particular abstract syntactic feature. General guidelines are: – If the information in question could be itself marked up with elements, put it in an
element, because attributes cannot contain such complex content;– If the information is suitable for attribute form (i.e., not complex), but could end up as multiple attributes of the same name on the same element, use child elements
instead, avoiding list datatypes for attributes;– If the information is required to be in a standard XML schema attribute type such as
ID, IDREF, ENTITY, KEYREF, use an attribute;– If the information should not be normalized for white space, use elements (XML processors normalize attributes in ways that can change the raw text of the attribute
value.). 5.2 LegalRuleML Syntactic RequirementsThe following syntactic characteristics were deemed mandatory for the LegalRuleML syntax: 1. An abstract syntax for LegalRuleML must be described by an RDFS metamodel. 2. Two equivalent XML-based concrete serializations of the abstract syntax must be specified: the normalized serialization and the compact serialization. Each constraint of the specification must be in one of the following formats: Relax NG grammar (RNC format), XSD 1.0 schema, or natural language statement. 3. Parsing from either LegalRuleML concrete serialization to the LegalRuleML abstract syntax in RDF/XML format must be specified by a composition of XSLT transformations. 4. A pair of abstract-syntax preserving XSLT transformations, called the compactifier and the normalizer, must convert LegalRuleML documents between compact and normalized serializations. 5. The conformance level of a document must be preserved by the compactification and normalization transformations. I.e., an XSD-conformant document must still be XSD-conformant after transformation, and similarly for RNC-conformance.
5.3 Syntactic ObjectivesThe following syntactic characteristics were deemed desirable for the LegalRuleML syntax, but could not all be simultaneously satisfied. The LegalRuleML syntax was designed to optimize over these characteristics to the extent possible: 1. maximize correspondence to the RDF-based abstract syntax representation in the normalized serialization.
2. minimize verbosity, especially in the compact serialization.3. minimize redundancy of expression, avoiding multiple ways to express the same thing. 4. minimize the difference between the syntax defined by the RNC and XSD schemas. 5. minimize the additional constraints not expressible in either RNC or XSD schemas. 6. minimize the additional constraints (from #5) not expressible through abstract-syntax preserving validating XSLT transformation. 7. (related to 5 and 6) minimize discrepancies after round-trip transformation between the compact and normalized serializations of instances that validate against RNC and XSD schemas.
8. minimize the modifications to imported RuleML schemas9. minimize the set of schema-conformant instances that do not satisfy a round trip law between serializations after projection by the abstract-syntax preserving validating transformations. 10. minimize the modifications that are necessary in the projections (as described in #9) to instances that satisfy the round-trip laws.
5.4 Node and Edge Element DichotomyIn order to satisfy objective 5.3.1, LegalRuleML adopted, for its normalized serialization, a form of striped syntax, where Node elements alternate with edge elements, forming a bipartite pattern, similar to the striped syntax of RDF/XML. The striped syntax of LegalRuleML normalized serialization is intended to represent explicitly the entity-relationship structure of the abstract syntax.
The LegalRuleML schemas specify two groups of elements: Node (also called type) elements and edge (also called role) elements, the element name of the former starting with an upper case letter, and the latter with a lower case letter. The one exception to this pattern is the <ruleml:slot> element, which is neither a Node or edge element.
Node elements correspond to classes of the metamodel while edge elements represent relationships between members of these classes. Edge elements correspond, in most cases, to properties in the metamodel. In a few cases, edge elements correspond to compositions of such properties. The ruleml:slot element also corresponds to the structure of the abstract syntax, with the first child of the slot corresponding to the property of a triple and the second child corresponding to the object of the triple.
In some cases, the metamodel is sufficiently restrictive so that the edge element provides no additional information, allowing for a lossless conversion from the normalized serialization to an XML representation that is less verbose by simply deleting the start and end edge tags. The LegalRuleML compact serialization is defined in this way.
In the XML document tree, elements that have no children are called branch elements, otherwise they are called leaf elements. Element types may be classified according to whether their instances are all leaf elements (Leaf type), all branch elements (Branch type) or either (Leaf/Branch type).
5.4.1 Node Elements The naming convention for Node elements is UpperCamelCase local names.The qualified name of a Node element corresponds to the type of the syntactic construct defined by the Node element, i.e., an rdf:type relationship in the RDF-based abstract-syntax representation (@@@ refer to metamodel section). The IRI of the metamodel class is constructed by concatenating local name of the Node element with the appropriate IRI prefix: * http://docs.oasis-open.org/legalruleml/ns/v1.0/metamodel# for Node elements in the LegalRuleML namespace * http://docs.oasis-open.org/legalruleml/ns/v1.0/rule-metamodel# for Node elements in the RuleML namespace We use the prefixes lrmlmm and rulemm, reps., to abbreviate the metamodel IRIs. At the time this document was published, the RuleML specification did not provide a metamodel, but a RuleML metamodel is under development @@@ref.
Classification of Node ElementsCollection Node element: In general, a Collection Node element is a Node element that defines a syntactic construct which is a collection. In LegalRuleML’s RDF-based metamodel, these constructs are of type rdf:List. The naming convention of Collection Nodes in LegalRuleML is to use the plural of the type of the members of the collection. For example, a collection for constructs of type lrmlmm:Authority is specified with an lrml:Authorities element. RuleML has no Collection Nodes.
Document Node element: In general, a Document Node element is a Node element that can serve as the root node of an instance document. In LegalRuleML, the element lrml:LegalRuleML is the only Document Node element.
Annotation Node element: In general, an Annotation Node element contains mixed content, and is intended to hold marked-up text. In LegalRuleML, the Annotation Nodes are the Nodes lrml:Comment and lrml:Paraphrase. RuleML has no Annotation Nodes.
In general, Node elements may have Leaf, Branch, or Leaf/Branch types. In the LegalRuleML namespace, all Nodes types are Leaf/Branch type, while in the RuleML namespace, Nodes types are mostly Leaf or Branch types, with a few exceptional Leaf/Branch types.
Every LegalRuleML Node element may optionally have a child element that attaches a comment to it, specified in an lrml:Comment element (see section @@@Comment/Paraphrase).
The types of RuleML Branch or Leaf/Branch Node element have been extended in the LegalRuleML syntax so that RuleML elements within a LegalRuleML document may optionally have a child element that attaches a paraphrase to it, specified in an lrml:Paraphrase element (see section @@@Comment/Paraphrase).
A group of common optional attributes for most LegalRuleML Node elements (called in the schemas commonLRMLNodeInit.attlist) are the following:
* @key * @keyref * @typewith the exception of <lrml:Reference> and <lrml:LegalReference>, which are not allowed to have these attributes. See section @@@Key/Keyref for details of the usage of @key and @keyref attributes, and @@@Metamodel Refinement for details of the usage of #type.
Common optional attributes for most RuleML Node elements within LegalRuleML documents are
* @key * @keyref * @xml:idThe @key and @keyref attributes have a different content model than the corresponding attribute in LegalRuleML elements (see section @@@Key/Keyref). The usage of the @xml:id attribute is described in @@@Identifiers
The root element of every LegalRuleML document is a Node element (in particular, <lrml:LegalRuleML>). This root element may optionally have the following attributes:
* @xml:base * @hasCreationDate * @xsi:schemaLocationin addition to the common optional Node attributes. The semantics of @xml:base and @xsi:schemaLocation are defined by the @@@XML and @@@XSD specifications, respectively. The @hasCreationDate attribute has semantics related to Dublin Core’s http://dublincore.org/documents/dcmi-terms/#terms-created, except that the Dublin Core property takes a literal value, while @hasCreationDate takes a local identifier reference to a ruleml:Time entity.
Specialized attributes may be optional or required for a subset of Node elements, as follows:
* @pre, on Prefix * @refID, on Prefix, Reference or LegalReference * @sameAs on Source, LegalSource, Agent, Authority, Jurisdiction* @iri on Annotation Nodes, Role, LegalRuleML Deontic Nodes and Deontic Key Nodes (@@@see Identifiers)
* @refersTo (on Reference and LegalReference)* @refType, @refIDSystemName, @refIDSystemSource (on Reference, References, LegalReference, LegalReferences)
* @memberType (on Collections) * @hasCreationDate (on LegalRuleML and Context) * @strength * @over, @underAdditionally, @xml:base is allowed on ruleml:Data elements with an explicit datatype of xsd:anyURI.
5.4.2 Edge Elements The naming convention for Node elements is lowerCamelCase local names. Classifications of Edge ElementsCollection Membership Edge: In the LegalRuleML namespace, collection membership edges are the children of Collection Nodes (defining syntactic constructs of type lrmlmm:Collection) that define the membership of the collection. The local names of these edges begin with ‘has’, followed by the name of the collection member type. For example, the collection edge for a lrml:Authorities collection is lrml:hasAuthority - the parent of an lrml:hasAuthority element is always lrml:Authorities, and its child is always lrml:Authority. English grammar conventions are followed when relating the plural form used in the name of the collection with the singular form used in the collection edge. Note that not all edges whose local name begins with ‘has’ are collection edges. In the RuleML namespace, an edge is a collection edge if and only if it has an @index attribute. The local names of RuleML collection edges are ‘arg’, ‘content’ and ‘formula’. The first two are always collection edges, while ruleml:formula is only a collection edge when its parent is ruleml:And, ruleml:Or, ruleml:Operation, or lrml:SuborderList.
Document Edge: In LegalRuleML, document edges are the edges whose parent Node element is the Document Node element, the root of the XML document. The local names of these edges begin with ‘has’, followed by the name of the (unique) child element.
Annotation Edge: In LegalRuleML, annotation edges contain an Annotation Node element. The local names of these edges begin with ‘has’, followed by the name of the (unique) child element.
The types of edge elements may be classified by syntactic type as Leaf, Branch or Leaf/Branch types. RuleML edge elements have only Branch types, while LegalRuleML edge elements have mostly Leaf (see section @@@Leaf Edge Elements) or Branch type (see section @@@Branch Edge Elements), with a few exceptional Leaf/Branch types (see section @@@Leaf/Branch Edge Elements).
The qualified name of an edge element, in most cases, corresponds to a property of the syntactic construct defined by its parent Node element, i.e., the property of a triple in the RDF-based abstract-syntax representation (@@@ refer to metamodel section). The IRI of the metamodel property is constructed by concatenating the local name of the edge element with the appropriate IRI prefix: * http://docs.oasis-open.org/legalruleml/ns/v1.0/metamodel# for Node elements in the LegalRuleML namespace * http://docs.oasis-open.org/legalruleml/ns/v1.0/rule-metamodel# for Node elements in the RuleML namespace with the exception of collection edges. The order in the collection is specified by the order of the sibling collection edges in the LegalRuleML document.
Edge elements may be classified as skippable or non-skippable, relative to the syntax. In the LegalRuleML namespace, it is exactly the Branch-type edge elements that are skippable, while Leaf-type and Leaf/Branch-type elements are non-skippable. Branch-type edges are the following:
* collection edges * document edges * annotation edges * the edges lrml:hasTemplate, except within lrml:FactualStatementThe RuleML edge elements that are considered skippable within LegalRuleML documents are the following:
* lrml:arg * lrml:op * lrml:formula * lrml:declare * lrml:strong * lrml:weak * lrml:left * lrml:right * lrml:torsoA group of common optional attributes for non-skippable LegalRuleML edge elements (called in the schemas commonLRMLEdgeInit.attlist) is defined, and contains only the following:
* @xml:idThe value of this attribute provides an identifier for the corresponding triple in the RDF-based abstract syntax representation.
Leaf-type edge elements have a required attribute that points to the object of the relationship they define. If the object is required to have a local identifier, then @keyref is the required attribute, otherwise it is @iri. Note that the Source, LegalSource, Reference, and LegalReference constructs are provided so that external resources can be aliased with a local identifier that may then be used as the value of an @keyref attribute.
5.5 Generic Node elementsA generic element is a main element whose syntax and/or semantics is underspecified unless an attached attribute attribute or header element provides a predefined value or an IRI pointer to a user-defined signature. For example, <ruleml:Operation> is a generic connective operator, which may be used for modal operators or logical connectives such as exclusive disjunction. Generic elements provide extension points for user-defined syntactic and semantic variation. The following table provides a listing of Generic Node elements and the attributes or header elements that may be used to specialize them.
ruleml:Operation @type ruleml:Negation @type ruleml:Rule @strength, hasStrength 5.6 SerializationsTwo equivalent normative serializations are defined in the Relax NG and XSD schemas – a normalized serialization and a compact serialization.
5.6.1 Normalized SerializationIn many cases, edge elements are redundant because they could be reconstructed based on the type or position of the parent and child node elements. RuleML syntax allows such edges to be optionally skipped, resulting in its stripe-skipped serialization. LegalRuleML syntax allows the two extreme cases - either no edges are skipped in the document (the normalized serialization) or all skippable edges in the document are omitted (the compact serialization). The normalized serialization may be reconstructed from a document in compact serialization by applying the normalizer XSLT transformation, which reconstructs the skipped edges.
5.6.2 Compact SerializationThe compact serialization of LegalRuleML reduces verbosity without loss of information. The compact serialization may be derived from the normalized serialization by removing the start and end tags of skippable edge elements. The compact serialization may be obtained from a document in normalized serialization by applying the compactifier XSLT transformation.
Note that RuleML has a relaxed serialization that allows edges to be optionally skipped, and also allows a (mostly) arbitrary ordering of child elements. RuleML in the relaxed serialization is not allowed to be embedded within LegalRuleML – the embedded RuleML must be in either normalized or compact serialization, consistent with the serialization of the parent LegalRuleML.
5.7 General Design Patterns Inside of LegalRuleML we employ five well-known design patterns:container, which is a structure of elements having independent existence (e.g.,<Context> can include several <Association> sub-elements); collection, a subpattern of container that is in the form of a list of elements of the same type (e.g., <Roles> that is a sequence of <Role> elements); recursive element (e.g., <Obligation> can include other <Obligation> elements); marker, an element that uses attribute @sameAs for identifying a source, e.g., <lrml:LegalSource key="sec504-clsa-pnt1" sameAs="&UScode;#title17-chp5-sec504-clsa-lst1-pnt1"/> composite elements that are made up of different dependent parts, (e.g., a rule <Rule> consists of an antecedent <if> and conclusion <then>).
5.7.1 Collection Design PatternLegalRuleML uses a collection design pattern for organizing and efficiently representing and referring to metadata. The lrmlmm:Collection class in the LegalRuleML metamodel is the superclass for these syntactic constructs, which is in turn a subclass of ref:List.
The lrmlmm:hasMember property The name of the collection element indicates the type of its members.Properties can be assigned to all members using an attribute on or header child element within the collection element. Metadata collections must occur in a prescribed order in a LegalRuleML document.
5.7.2 Recursive Element PatternThe RuleML syntax uses recursive elements, i.e. elements that may have descendants of the same name, to represent the inherently recursive nature of logical connectives and functional expressions. LegalRuleML introduces some specialized logical connectives which are similarly recursive, as follows:
* lrml:Obligation * lrml:Permission * lrml:Prohibition * lrml:Right * lrml:SuborderListIn order to reduce redundancy through modularization, some of the collections elements are recursive, as follows:
* lrml:Sources * lrml:LegalSourcesSimilarly, the element that is used to efficiently construct contextual relationships is recursive to facilitate modularization:
* lrml:Association 5.7.3 Marker Interface PatternThe marker interface pattern is used in programming to annotate entities. In LegalRuleML, external entities are in many cases required to be aliased with a local identifier, which may then be referenced as the subject or object of annotations. The syntax that implements the marker interface pattern in LegalRuleML consists of the following attributes:
* @key * @keyref * @sameAs * @refersTo * @refID 5.7.4 Composite Element Pattern@@@This is a foundational design decision for the metamodel. There are pros and cons to the composite element pattern. The parser to the abstract syntax is currently written in a way that does *not* invoke the composite element pattern. In particular, if there is a Node element with a @keyref attribute and no content, a triple is created that has the IRI from that keyref as object - a clone of the object is *not* created.
As a consequence, a formula could be the head of two different rules.If we have the composite element pattern, then each rule owns its head (and body), so the two different rules must have two different heads, even if they are occurrences of the same proposition.
@@@ 5.8 Specialized Design Patterns 5.8.1 Ordered-Children Design PatternIn the normalized serialization, when the order of children is significant to the semantics of the parent Node element, an index attribute is required on the edges so that the order is made explicit. In the compact serialization, the edge elements that would have an index attribute are skipped, so that the order of occurrence of children in the XML document is significant.
Example: SuborderList 5.8.2 Leaf edgesLegalRuleML introduces a syntactic pattern that is not present in RuleML – the leaf edge element:
is an edge element that is empty always has at least one attribute, typically @keyref See stripe_leaf_module.rnc (Stripe Required, Leaf Not Obligatoryand Stripe Optional, Leaf Not Obligatory) and stripe_required_module.rnc (Leaf Obligatory)
5.8.3 Slot Design PatternLegalRuleML adopts the slot design pattern as implemented in RuleML for expressing properties of deontic formulas. This design pattern comes from frame language and serves to store information about a frame as a "property-value" pair.
5.9 CURIES, Relative IRIs and the xsd:ID Datatype• LegalRuleML employs a variety of syntactic forms for labeling components with identifiers, and for referring to these or other identifiers. In this section, we discuss the syntactic forms that are based on the IRI system, and compare to the corresponding forms employed in RuleML.
Need overview of prefixing and abbreviation of IRIs qualified names (<ruleml:Rule>, “xs:integer”) xsd:ID datatype (key = “rule1”) same-document reference (keyref = “#rule1”) relative IRIs other than same-document reference (“../otherdoc.lrml#rule2”) CURIEs (iri=”ex:servb/otherdoc.lrml”, keyref=”:#rule1”) IRI (iri=”http://servb/otherdoc.lrml”;) CURIE datatype follows RDFa (@@@citation)conflicting ID-types for attribute “key” of element “TemporalCharacteristic” from namespace “http://docs.oasis-open.org/legalruleml/ns/v1.0/”;
5.10 Distributed SyntaxThe @key and @keyref attributes are used to enable the distributed definition of syntactic constructs in both RuleML and LegalRuleML namespaces. The @key attribute supplies a local identifier for the syntactic construct, and . In particular, the value of the @key attribute, of datatype xs:ID, is concatenated with the base IRI of the LegalRuleML document (as specified by the xml:base attribute on the root, if present, and otherwise determined according to @@@) to construct the IRI of the syntactic construct defined by the parent Node element of the @key attribute.
The @keyref is used to reference the local identifiers defined by @key attributes. It is a syntactic error for a @keyref attribute to have a value that does not correspond to a local identifier in the same document.
When @keyref occurs on an element with no attributes or content, then it is reference to the syntactic construct having that local identifier. When @keyref occurs on a parent element that has attributes and/or content, it refers to a new syntactic construct that is based on the referenced construct, modified by the attributes and/or content of the parent. Such elements are translated into the abstract syntax using the lrmlmm:mergerOf property.
Taking into account the simultaneous occurrence of @key and @keyref attributes on the same element, these references form a directed graph which must be acyclic; it is a syntactic error if this graph is not acyclic.
5.11 Metamodel RefinementThe @type attribute is used to refine the semantics of LegalRuleML elements by reference to external resources. An @type attribute on any element is translated into the abstract syntax as an RDF triple with property rdf:type. From this, it may be inferred that the resource is an rdf:Class, and the syntactic construct defined by the element on which it occurred is an instance of that class, as well as an instance of the class of the LegalRuleML metamodel corresponding to the element’s name. Note that the @type attribute has quite different semantics on RuleML elements (see @@@RuleMLSpec).
5.12 Annotations - Comment and Paraphrasre 5.13 Identifiers - @xml:id and @iriAn @iri attribute on a Node element correspond to an owl:sameAs relationship in the abstract syntax.
5.14 Relax NG Schema DesignThe normative definition of the LegalRuleML syntax is provided by modular Relax NG schemas.
5.14.1 ModulesThe Relax NG schema modules are written in the “chameleon” style, without specifying a target namespace, to maximum the potential for re-use. The LegalRuleML modules follow the monotonic design pattern (citation @@@) developed for the RuleML 1.0 Relax NG schemas and again employed in RuleML Version 1.01 and 1.02, for best compatibility with the included RuleML modules. This design pattern is based on restricting the Relax NG syntax in a manner that guarantees monotonicity when schema modules are mixed together. That is, a language defined by a subset of the modules of another language will be a sublanguage of it.
5.14.3 Drivers Core Compact and Normal LRML Drivers 5.15 XSD Schema Derivation 5.5.1 Alternate DriversTo accomplish the automated conversion from Relax NG to XSD, alternate driver schemas were constructed (lrml4xsd-compact and lrml4xsd-normal). These schemas differ from the normative Relax NG schemas only in the following ways: * inclusion of a different module (modules-xsd/id_datatype_ID) defining the type of the key attribute in LegalRuleML elements to be xsd:ID. * inclusion of a different module (modules-xsd/time4xsd) defining the type of <ruleml:Data> within <ruleml:Time> to be xs:any. * inclusion of a different module (modules-xsd/stripe_required_4xsd) defining the Leaf/Branch-type edge elements by a lenient pattern that is exactly expressible in XSD
* inclusion of a modified RuleML schema suitable for conversion to XSD. 5.15.2 Alternate Relax NG Modules id_datatype_ID time4xsd 5.15.3 Conversion using TrangThe Trang software (https://code.google.com/p/jing-trang/downloads/detail?name=trang-20091111.zip) was used to convert the Relax NG schemas into XSD, selecting he options to disable abstract elements and select lax processing of elements of type xs:any.
5.15.4 Post-processing with XSLTDue to differences in the expressivity of the Relax NG and XSD schema languages, and the particularities of the Trang software used to make the conversion, some post-processing of the generated XSD was necessary to obtain a valid XSD schema that appropriately approximates the original Relax NG schemas. The post-processing was accomplished with XSLT transformations @@@/xslt/compact-rnc2xsd.xslt and @@@/xslt/normal-rnc2xsd.xslt.
5.16 Differences between RNC and XSD Schemas 5.16.1. xsi:typeXSD schemas allow no constraint on the appearance of the xsi:type attribute (as in http://www.w3.org/TR/xmlschema-1/#no-xsi), nor may they alter the definition from the definition built into XSD schemas (@@@ref XSD Schemas). As a consequence, to be XSD valid, the value of any xsi:type attribute must correspond to some predefined type (e.g. xsd:string) or a user-defined type in the schema, such as the RuleML complex types, e.g. ruleml:integer that permits attributes (e.g. key) on the Data element while still constraining the content to be of type xsd:integer. Further, XSD validation requires that the attributes and content of the element on which the xsi:type attribute appears must conform to that specified type definition.
RNC schemas intentionally treat an xsi:type attribute just like any other attribute, so it must be explicitly implemented. It is not possible to implement the xsi:type attribute in Relax NG in a way that is equivalent to its nature in XSD schemas.
RuleML uses the xsi:type attribute on the <ruleml:Data> element to manage the datatype. The RuleML RNC schemas implement a limited form of the xsi:type attribute on <ruleml:Data>, such that only certain types are allowed. In particular, the XSD datatypes are allowed, and user-defined datatypes in the RuleML namespace are implemented which allow attributes on the ruleml:Data element in addition to simple content according to a particular XSD datatype. Otherwise, RuleML does not permit the use of xsi:type on elements in the RuleML namespace, a constraint enforced by the normative RNC schemas.
LegalRuleML introduces no additional elements where the use of xsi:type is appropriate, and does allow embedded <ruleML:Data> with xsi:type attributes to be validated by the LegalRuleML RNC, through importing the corresponding RNC schema module. In addition, LegalRuleML derives a restricted <ruleml:Data> element for use in temporal characteristics. This use of xsi:type is fully supported in the XSD schemas by default, but the XSD schemas are not able to express the constraint against other uses of xsi:type attributes, and thus are lenient in this regard, relative to the RNC schemas.
5.16.2. xsi:schemaLocationLike other attributes in the xsi namespace, XSD schemas may not constrain the occurrence of the xsi:schemaLocation attribute or alter the definition from the definition built into XSD schemas (@@@ref XSD Schemas).
RNC schemas treat xsi:schemaLocation just like any other attribute. RuleML implements the xsi:schemaLocation attribute in the RNC schemas, and allows it to appear in any element.
For LegalRuleML, the occurrence of the xsi:schemaLocation attribute on a skippable edge causes problems in regard to objective #7, due to inability to reconstruct the attribute because it is deleted along with the edge tags during compactification. In actuality, there does not appear to be any usecase for the xsi:schemaLocation attribute on any element other than the root element of the LegalRuleML document. For this reason, the xsi:schemaLocation attribute is implemented in the LegalRuleML RNC schemas in this restricted fashion, and the RuleML module that implements the xsi:schemaLocation attribute on elements in the RuleML namespace is not included. This is a sacrifice of objective #4 in favor of objective #7.
Therefore, the Relax NG schemas are more restrictive than the XSD schemas in this regard.
5.16.3. xsi:nil and xsi: noNamespaceSchemaLocationAgain, XSD schemas allow these attributes to occur anywhere. In both LegalRuleML and RuleML, these attributes are not defined in the RNC schemas, and so are not permitted anywhere in instances that meet the RNC conformance criterion. Again, the Relax NG schemas are more restrictive than the XSD schemas in this regard.
5.16.4. xml:baseAttributes in the xml namespace do not have built-in definitions in either XSD or RNC schemas, and so must be explicitly defined if their use is desired.
In RuleML, the xml:base attribute may appear only on the <ruleml:Data> element, where it may be used in the resolution of a data value that is a relative IRI.
In LegalRuleML, the xml:base attribute is additionally permitted on the document root <LegalRuleML> element.
RNC and XSD schemas express this equivalently. 5.16.5. @xml:idIn the original RuleML grammar, the xml:id attribute is allowed on any element, although there is a compatibility requirement with an xsi:type attribute if both appear on a Data element. This causes problems in regard to objective #7 if xml:id appears on a skippable edge, since the information is lost upon compactification.
In LegalRuleML, @xml:id, or any other attribute, is not allowed on skippable edges in the lrml namespace through the LegalRuleML RNC schemas.
In order to satisfy objective #7 as fully as possible, while somewhat sacrificing #8, the @xml:id attribute is disallowed on skippable RuleML edges that are embedded in LegalRuleML documents. This is accomplished in both RNC and XSD schemas through redefining the imported RuleML RNC modules prior to conversion to XSD.
A separate issue is in regard to enforcing the uniqueness of xml:id values within a document. This is partially accomplished by the XSD schemas. It is not possible to enforce this at all in the RNC schemas due to some interference from wild card patterns, a known issue ( https://github.com/relaxng/jing-trang/issues/178 ). This means the XSD schemas are necessarily more restrictive than the RNC schemas in this regard.
5.16.6 @key/@keyrefIn the original RuleML grammar, the key and keyref attributes are allowed on all elements, including skippable edges. Since key has an IRI (or CURIE) datatype rather than an xsd:ID datatype, it is not incompatible with the xml:id attribute, and so both are allowed to occur on the same element. Like xml:id discussed above, this causes problems in regard to objective #7. This is only an issue on skippable edge in the RuleML namespace. In RuleML, what is "skippable" varies somewhat depending on the expressivity. In some languages, <ruleml:if> and <ruleml:then> edges are skippable, and in others they are not. In LegalRuleML, <ruleml:if> and <ruleml:then> edges, within either Rule or Implies elements, are not skippable.
In order to satisfy objective #7 as fully as possible, while somewhat sacrificing #8, the @key attribute is disallowed on skippable RuleML edges that are embedded in LegalRuleML documents. This is accomplished in both RNC and XSD schemas through redefining the imported RuleML RNC modules prior to conversion to XSD.
As mentioned in item 5.16.5, the xsd:ID datatype for key on LegalRuleML elements is enforced by the XSD but not the RNC schemas. This imposes a uniqueness requirement on the key attribute but only relative to other attributes with xsd:ID datatype, which does not include @key on RuleML elements, but does include xml:id attributes.
5.16.7 Document Root ElementThe LegalRuleML RNC schemas enforce the requirement that the root element is lrml:LegalRuleML. This requirement is not enforce in the XSD schemas, although it could be done with a refactoring of the definitions. The challenge is that any element defined at the global level in an XSD schema is allowed to be the root element. To restrict the XSD schema so that only LegalRuleML elements may be the root, all element definitions would have to be contained within the definition of the LegalRuleML element. For enhanced readability of the XSD schemas, this requirement is thus only enforced by the RNC schemas.
5.16.8 Leaf/Branch Type EdgesEdges of this type, which only occur in the LegalRuleML namespace, may optionally have a child element and optionally may have attributes. When there is a child, the attributes on the edge are typically meaningless, except for xml:id which serves simply to label the edge. When the conversion is made to the RDF-based representation of the abstract syntax, the key and keyref attributes are ignored, while an xml:id attribute is honored. Thus if a document is parsed into the abstract syntax through the XSLT to RDF, and then serialized back into the XML syntax, the (meaningless) key and keyref attributes are lost. The ideal solution would be to disallow the @key and @keyref attributes on this type of edge element. Unfortunately, it is not possible to construct an XSD 1.0 schema that allows attributes on the edge only when it does not have a child. However this is possible with RNC, and probably is possible with Schematron or XSD 1.1. Also, the removal of such (meaningless) attributes is easily accomplished with XSLT, so a validating XSLT transformation can be constructed for this constraint.
The RNC schema main drivers (schemas/relaxng/lrml-compact.rnc and schemas/relaxng/lrml-normal.rnc) implement the choice (exclusive or) between attributes and content on edges of Leaf/Branch type. This favors objective #3, as well as clarity, at the expense of an additional deviation between RNC and XSD schemas. The RNC schema drivers that are used for the conversion to XSD (schemas/relaxng/lrml4xsd-compact.rnc and schemas/relaxng/lrml4xsd-normal.rnc) implement the attributes and content of Leaf/Branch-type edges as an inclusive or, so that the converter does not need to approximate.
There is a validator XSLT (xslt/validators/lrml_validator-leaf-branch.xslt) that strips these attributes away from a LegalRuleML document, and also uses the xsl:message capability to inform the user when such attributes were present in the input.
5.17 Prefix Mapping XSLT TransformationA number of RuleML and LegalRuleML attributes have values which should be treated as CURIEs. That is, they should be evaluated to IRIs according to a prefix mapping, which is defined by the Prefix element.
The XSLT at xslt/normalizer/lrml_normal_canonicalizer.xslt performs CURIE evaluation, in addition to some other modifications, as preparation for appying the parsing XSLT that produces RDF (schemas/xslt/triplifyMerger-ids.xsl)
This evaluation also applies to the values of @refID within Reference and LegalReference, which are not constrained to be IRIs or CURIEs. The choice of xs:string for the datatype of the prefix mapping (also called @refID) enables this usage, allowing CURIE-like abbreviation to be used within Reference and LegalReference, as illustrated in examples/draft/ex2.1.10.a-v1-compact.lrml for identifiers of Akoma Ntoso.
5.18 The following constraints are enforced by neither RNC nor XSD schemas:5.18.1. The prefix mappings and the abbreviations they are to apply should be such that the evaluation result is conformant to the schema(s).
5.18.2. RuleML collection edges, i.e. those edges with @index attributes, must have values of @index in agreement with their position in the node set of sibling collection edges.
5.18.3. IRIs occurring as attribute values, whether originally expressed as an IRI or a CURIE, are required to be fully conformant to RFC 3987[18]. In the case of CURIEs, this restriction applies after expansion to an IRI according to the prefix.
5.18.4. The value of any keyref attribute must match the value of a key attribute within the @@@key/keyref closure of the@@@ document.
5.18.5. Each occurrence of @key on LegalRuleML and RuleML elements must have a unique value (after deletion of the leading colon on values of @key within RuleML elements) within the @@@key/keyref closure of the@@@ document.
5.18.6. In the LegalRuleML RDF abstract syntax representation, triples whose properties correspond to skippable edges in the concrete syntax must not be reified.
5.19 Validating XSLT Transformations5.19.1 Conformance to the additional constraint 5.18.1 may be checked by applying the XLST transformation /xslt/normalizer/lrml_prefix_evaluation.xslt , and validating the output.
This transformation is abstract-syntax preserving.5.19.2 Conformance to the additional constraint 5.18.2 may be checked through the XLST transformation /xslt/validator/lrml_sequential-indexing.xslt . This transformation is abstract-syntax preserving when applied following the /xslt/validator/lrml_sequential-indexing.xslt transformation .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]