[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