Working Draft 18 July 2001
- This version:
- Working Draft: 18 July 2001
Copyright © The Organiz!
ation for the Advancement of
Structured Information Standards [OASIS] 2001. All Rights
Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to OASIS, except as needed for the
purpose of developing OASIS specifications, in which case the
procedures for copyrights defined in the OASIS Intellectual Property
Rights document must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided
on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
...
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.
We now formalize key-ambiguity. First, we introduce the concept
that two pattern compete. An
element pattern <element>
nc1 top1
</element> and another element pattern
<element> nc2
top2 </element>
compete if some name matches both
nc1 and nc2. An
attribute pattern <attribute>
nc1 pattern1
</attribute> and another attribute
pattern <attribute> nc2
pattern2 </attribute> compete
if their nearest ancestor element patterns compete
and some name matches both nc1 and
nc2. A schema is key-ambiguous if two element or
attribute patterns compete and they have different
key-types.
Finally, we introduce the concept of a
key-type. A key-type is one of notKey, key,
keyRef, keyList or keyRefList. Each key-type other than notKey has a
parameter which is a name. We use the following notation:
-
notKey( )
- constructs a notKey key-type
-
key( n )
- constructs a key key-type with parameter n
-
keyRef( n )
- constructs a keyRef key-type with parameter n
-
keyList( n )
- constructs a keyList key-type with parameter n
-
keyRefList( n )
- constructs a keyRefList key-type with parameter n
-
kt
- ranges over key-types
-
p :k kt
- asserts that kt is a possible key-type for
pattern p
The following rules define what the key-types of a pattern are.
| (data) | <data datatypeLibrary="u" type="ln"> params </data> :k notKey( ) |
|
| (value) | <value datatypeLibrary="u1" type="ln" ns="u2"> s </value> :k notKey( ) |
|
| (key) | <key name="ln" ns="u"> p </key> :k key( name( u, ln ) ) |
|
| (keyRef) | <keyRef name="ln" ns="u"> p </keyRef> :k keyRef( name( u, ln ) ) |
|
| (keyList) | | p :k key( n ) |
| <list> p </list> :k keyList( n ) |
|
| (keyRefList) | | p :k keyRef( n ) |
| <list> p </list> :k keyRefList( n ) |
|
| (list) | | p :k notKey( ) |
| <list> p </list> :k notKey( ) |
|
| (contains) | | p1 :k kt | p2 contains p1 |
| | p2 :k kt |
|