[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: My rewrite of Section 7 with notes
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> Note: James excluded the following paths. > anyName/except//anyName > nsName/except//nsName > nsName/except//anyName 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> Note: James excluded the following paths. > data/except//group > data/except//interleave > data/except//oneOrMore > data/except//key > data/except//keyRef > data/except//list > data/except//attribute > data/except//element > data/except//text 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> Note: James excludes the following paths. > list//list > list//element > list//attribute > list//text 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: James excluded the following paths. I excluded a lot more. Thus, <keyRef> in <list> is very restricted. See (3) and (4) in my mail [1]. [1] http://lists.oasis-open.org/archives/relax-ng/200107/msg00270.html > key//key > key//keyRef > key//list > key//element > key//attribute > key//group > key//interleave > key//oneOrMore > key//text Note: Unlike in the current spec, <list><key>...</key></list> is disallowed. If we decide to allot it, the second rule requires two mone lines as below: | <list><oneOrMore><key ns="anyURI" name="NCName"> dataValue </keyRef></oneOrMore></list> Note: Unlike in the current spec, <choice> of <key>s of the same datatype and <choice> of <keyRef>s of the same datatype are disallowed. If they are required, the second line of the first rule should read | <choice> (<empty/> | identityConstraint) identityConstraint </choice> Note: As in the current spec, <choice> below <key>/<keyRef> is allowed. If it is unnecessary, we can use dataValue rather than dataValueChoice. 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> Note: James excluded the following paths. > attribute//element > attribute//attribute 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> Note: James excluded the following paths. I excluded a lot more (Issue 45), thus simplifying the BNF significantly. If we do not accept the restriction in Issue#45, we need non-terminal "repeatable". > oneOrMore//group//attribute > oneOrMore//interleave//attribute 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. Note: This restriction is already in our spec. 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/>. Note: This restriction is also in our spec. 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> Note: Unlike in the current spec, use of identity constraints in <group>, <interleave>, is explicitly restricted. Rather, the current spec disallows such <group> and <interleave> by the semantic rules in 7.4. Note: Unlike in the current spec, <choice> of <key>s of the same datatype and <choice> of <keyRef>s of the same datatype are disallowed. If they are necessary, the third and forth lines of the third rule should read: | <choice> (<empty/> | attributeGroup | identityConstraint) identyConstraint </choice> | <choice> (<empty/> | identityConstraint) (attributeGroup | identyConstraint) </choice> Note: If we disallow use of elements as ID/IDREF/IDREFS, the rule for top becomes "top ::= <notAllowed/> | <empty/> | nonEmptyPattern". Note: I do not think that restrictions in this subsection can be captured by disallowing some paths. James did not try to do so. 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. ---- Murata Makoto mura034@attglobal.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC