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



Proposal for the ID/IDREF constraint
------------------------------------


This post assumes the following requirements.

1. we can't live without ID/IDREF feature
2. but we can live without key/keyref feature that we see in XML Schema.

And this post proposes a set of constraints that should be enforced only
when TREX is used with XML Schema datatypes. This constraint (or similar
constraint) is necessary, because validators CANNOT work without these
constraints.

This constraint is defined in terms of "normal form" that James Clark
proposed.

1. ID, IDREF, and their derived types can only appear as a direct child
   of attribute pattern. Also, they cannot have any siblings.

2. parent attribute pattern must have a simple name.

   In short, it must be the form of 

<attribute>
  <name>...</name>
  <data type="id" />
</attribute>

3. Any attribute pattern that accepts this name must have the same type.

That is,

<define name="...">
 ...
   <attribute name="foo">
    <data type="id" />
   </attribute>
 ...
</define>

<attribute name="foo">
  <data type="string" />
</attribute>

is not allowed because two attribute patterns, which share the same name
"foo", have different type.

----------------
end of proposal

--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@eng.sun.com



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


Powered by eList eXpress LLC