[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: My rewrite of Section 7 without notes
I tried to do editorial changes to 7.1. But I find it difficult to separate editorial changes and my technical concerns, since all my technical concerns about 7.1 and 7.4 are so closely relevant to the editorial changes I would like to make. Rather, I have somtimes incoporporated technical changes I would like to make. This mail presents my rewrite of Setion 7. The next mail further contains notes explaining the changes I have made. If you do not already understand section 7, it might be a good idea to read tihs mail so as to have some understanding of the restrictions in Section 7. Cheers Makoto ------------ 7.1 Composition 7.1.1 Patterns describing name classes This subsection introduces restrictions on name classes. If an <nsName> has an <except>, the child name class of the <except> permits at most a finite number of names. nsName ::= <nsName ns="anyURI"> [<except> finiteNameClass </except>] </nsName> finiteNameClass ::= name | <choice> finiteNameClass finiteNameClass </choice> name ::= <name ns="anyURI"> NCName </name> If an <anyName> has an <except>, the child pattern of the <except> satisfies the following restriction: for each namespace, either (1) the child pattern allows at most a finite number of names in that namespace, or (2) the child pattern disallows at most a finite number of names in that namespace. anyName ::= <anyName> [<except> nsNameClass </except>] </anyName> nsNameClass ::= name | nsName | <choice> nsNameClass nsNameClass </choice> Finally, name classes are restricted as below: nameClass ::= anyName | nsName | name | <choice> nameClass nameClass </choice> 7.1.2 Patterns describing datatypes and values This subsection introduces restrictions on patterns (i.e., <data>) for describing datatypes. Child patterns of <except> are either <data> or <value> patterns, or <choice>s of such patterns. dataValue ::= <data datatypeLibrary="anyURI" type="NCName"> param* [exceptPattern] </data> | <value datatypeLibrary="anyURI" type="NCName" ns="anyURI"> string </value> param ::= <param name="NCName"> string </param> exceptPattern ::= <except> dataValueChoice </except> dataValueChoice ::= dataValue | <choice> dataValueChoice dataValueChoice </choice> 7.1.3 Patterns describing lists of tokens This subsection introduces restrictions on patterns (i.e., <list>) describing sequences of datatypes or values. <list> patterns mimicking IDREFS are discussed later. The content of <list> is constructed by combining <data> and <value> patterns with <oneOrMore>, <group>, <interleave>, and <choice>. As a special case, <empty> is allowed as the content of <list> as well as the first child of <choice>. list ::= <list> (<empty/> | tokens) </list> tokens ::= dataValue | <oneOrMore> tokens </oneOrMore> | <group> tokens tokens </group> | <interleave> tokens tokens </interleave> | <choice> (<empty/> | tokens) tokens </choice> 7.1.4 Patterns describing identity constraints (i.e., <key> and <keyRef>) This subsection introduces restrictions on patterns describing identity constraints. Such pattenrs are <key>, <keyRef>, or <list><oneOrMore><keyRef>...</keyRef></oneOrMore> patterns, which capture ID, IDREF, or IDREFS of DTDs, respectively. Identity constraints are optional. identityConstraint ::= atomicIdentityConstraint | <choice> <empty/> atomicIdentityConstraint </choice> atomicIdentityConstraint ::= <key ns="anyURI" name="NCName"> dataValueChoice </key> | <keyRef ns="anyURI" name="NCName"> dataValueChoice </keyRef> | <list><oneOrMore><keyRef ns="anyURI" name="NCName"> dataValueChoice </keyRef></oneOrMore></list> Note: I want to use keywords ID and IDREF rather than key and KeyRef. Furthermore, I would like to introduce a syntax sugar <IDREFS ns="anyURI" name="NCName"> dataValue </IDREFS> which is equivalent to <list> <oneOrMore> <keyRef ns="anyURI" name="NCName"> dataValue</keyRef> </oneOrMore> </list>. 7.1.5 Patterns describing strings without elements, attributes, or identity constraints This subsection introduces restrictions on patterns describing strings without elements, attributes, or identity constraints. These patterns are either <text>, <data>, <value>, or <list> patterns, or <choice>s of such patterns. value ::= dataValue | <text/> | list | <choice> (<empty/> | value) value </choice> 7.1.6 Patterns describing attributes This subsection introduces restrictions on patterns describing at most one attribute. These patterns are either <empty> or <attribute> patterns, or <choice>s of such patterns. The second child of an <attribute> is either (1) <empty/>, (2) a pattern describing identity constraints, or (3) a pattern describing strings without elements, attributes, or identity constraints. singleAttributeGroup ::= <attribute> nameClass (<empty/> | identityConstraint | value) </attribute> | <choice> (<empty/> | singleAttributeGroup) singleAttributeGroup </choice> Patterns describing collections of attributes are constructed by combining <attribute> or <empty> with <oneOrMore>, <group>, and <interleave>. attributeGroup ::= singleAttributeGroup | <oneOrMore> singleAttributeGroup </oneOrMore> | <group> attributeGroup attributeGroup </group> | <interleave> attributeGroup attributeGroup </interleave> | <choice> (<empty/> | attributeGroup) attributeGroup </choice> 7.1.7 Patterns describing contents of elements There are two restrictions on patterns describing the content of elements. First, <oneOreMore> cannot directly or indirectly contain patterns describing collections of attributes. Second, a <data> or <value> pattern or a <choice> pattern (directly or indirectly) containing a <data> or <value> pattern cannot be <group>ed or <interleave>ed with other <data>, <value>, <ref>, or <text/>. mixed ::= <ref name="NCName"/> | <text/> | <group> mixed mixed </group> | <interleave> mixed mixed </interleave> | <choice> (<empty/> | mixed) mixed </choice> | <oneOrMore> mixed </oneOrMore> nonEmptyPattern ::= attributeGroup | value | mixed | <choice> (<empty/> | nonEmptyPattern) nonEmptyPattern </choice> | <group> attributeGroup nonEmptyPattern </group> | <group> nonEmptyPattern attributeGroup </group> | <interleave> attributeGroup nonEmptyPattern </interleave> | <interleave> nonEmptyPattern attributeGroup </interleave> top ::= <notAllowed/> | <empty/> | nonEmptyPattern | identityConstraint | <choice> (<empty/> | attributeGroup) identyConstraint </choice> | <choice> (<empty/> | identyConstraint) attributeGroup </choice> | <group> identityConstraint attributeGroup </group> | <group> attributeGroup identityConstraint </group> | <interleave> identityConstraint attributeGroup </interleave> | <interleave> attributeGroup identityConstraint </interleave> 7.1.8 Patterns describing grammars define ::= <define name="NCName"> <element> nameClass top </element> </define> grammar ::= <grammar> <start> top </start> define* </grammar> 7.2 Duplicate attributes ... 7.3 Interleave ... 7.4 key and keyRef Every key symbol space must have a unique datatype. More precisely, for every local name n and namespace URI uri, there must be a unique datatype name d in datatype library L, such that for every key and keyRef element with name attribute equal to n and ns attribute equal to uri, all data and value descendant elements have a type attribute with value d and a datatypeLibrary attribute with value L. It must be possible to determine for any element or attribute whether it is a key or key reference and, if so, the symbol space of the key or key reference, by examining just the name of the element or the name of the attribute and its parent element. A RELAX NG schema that does not satisfy this constraint is said to be key-ambiguous. A RELAX NG schema that is key-ambiguous is not correct. First, we define when two patterns have the same key-type. A pattern p1 and another pattern p2 are of the same key-type when case 1: key or keyRef does not occur in p1 and does not occur in p2. case 2: - key occurs in both p1 and p2, - keyRef occurs neither in p1 nor in p2, - all key elements in p1 and p2 specify the same value for the attibute "name" and specify the same value for the attribute "ns", and + none of the key elements in p1 or p2 have <oneOrMore> as the parent (i.e., IDS), or + all of the key elements in p1 or p2 have <oneOrMore> as the parent (i.e., ID); case 3: - keyRef occurs in both p1 and p2, - key occurrs neither in p1 nor in p2, - all keyRef elements in p1 and p2 specify the same value for the attibute "name" and specify the same value for the attribute "ns", and + none of the keyRef elements in p1 or p2 have <oneOrMore> as the parent (i.e., IDREFS), or + all of the keyRef elements in p1 or p2 have <oneOrMore> as the parent (i.e., IDREF). A schema s is key-ambiguous if Case 1: + s contains two element patterns <element> nc1 top1 </element> and <element> nc2 top2 </element>, + some name matches both nc1 and nc2, and + top1 and top2 are not of the same key-type. or Case 2: + s contains two attribute patterns <attribute> nc1 pattern1 </attribute> and <attribute> nc2 pattern2 </attribute>, + some name matches both nc1 and nc2, + some name matches both nc1' and nc2', where nc1' is the name class of the nearest ancestor <element> pattern of the first <attribute> and nc2' is the name class of the nearest ancestor <element> pattern of the second <attribute>, and + pattern1 and pattern2 are not of the same key-type.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC