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

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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