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: ID/IDREF strawman


Here is a strawman proposal to satisfy the requirements for our ID/IDREF
replacement mechanism that we identified at the telcon.

Introduce two new elements, <key>, <keyRef>.  These each have a required
name attribute whose value is an NCName.  There content is either empty or a
pattern.  Empty content is equivalent to <anyString/> (as with <attribute>).

There are the following restrictions on key, keyRef:

- the content pattern must not allow elements or attributes

- the content pattern must not contain key, keyRef

- there is the same restriction on grouping key, keyRef that there is with
grouping data/string

- use of key, keyRef must be unambiguous in the sense that you can always
unambiguosly determine the name of a key/keyRef (if any) that an element or
attribute contains  (more on this in a subsequent message)

- all key/keyRefs of a particular name must have the same content pattern
(or at least the same base datatype)

The informal semantics are as follows.  A forest matches an key/keyRef
pattern if it matches the content pattern.  Matching a sequence of
characters (ie a text node) against a key/keyRef pattern has the side-effect
of "tagging" the text node as being a key/keyRef of a particular name.  The
document matched as a whole must satisfy the following constraints:

- for any key name x, all text nodes tagged as being keys named x must have
distinct values

- for any key name x, for any text node n tagged as being keyref named x
there must be a text node n' tagged as being a key named x such that the
values of n and n' are equal

For example, in cases where you might say:

<attribute name="id">
   <data type="xsd:ID"/>
</attribute>

you would instead say:

<attribute name="id">
   <key name="whatever"/>
</attribute>

or if you want to restrict IDs to being NMTOKENs, you would do:

<attribute name="id">
   <key name="whatever">
       <data type="xsd:NMTOKEN"/>
   </key>
</attribute>

Similarly, instead of:

<attribute name="ref">
  <data type="xsd:IDREF"/>
</attribute>

you might say:

<attribute name="ref">
   <keyRef name="whatever"/>
</attribute>

Describing the semantics and restrictions rigourously is going to be quite
"interesting".

James






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC