Re: Type-assignment (was Re: Are we losing out because of grammars?)

["K.Kawaguchi" <k-kawa@bigfoot.com>]

> My current thinking is that the ID/IDREF approach to uniqueness
> constraints doesn't really scale. For example, there's no way I can see
> to make it handle multipart keys. ID isn't purely a datatype in the same
> way that NMTOKEN is: making an attribute have type ID has side-effects
> on the validity of other attributes that making an attribute have type
> NMTOKEN does not.  I think it's better therefore to move to a completely
> different approach to handling uniquessnes and cross-reference
> constraints, more along the lines of the identity constraints in W3C's
> XML Schemas.

I second you! 



> Another interesting issue with ID and with type-assigment is how it
> interacts with intersection (the "concur" operator in TREX).  What do I
> do with something like this

Since your example uses <concur>, every attribute "a" must be
considered as ID and there are no other possible interpretation.

Things get tricky if you change <concur> to <choice>. We can't decide
any more whether "a" attribute is ID.

And I guess that what you intended.

> <choice>
>   <element name="e">
>     <attribute name="a">
>       <data type="xsd:ID"/>
>     </attribute>
>   </element>
>   <element>
>     <anyName/>
>     <zeroOrMore>
>       <attribute>
>         <anyName/>
>       </attribute>
>     </zeroOrMore>
>   </element>
> </choice>

regards,
----------------------
K.Kawaguchi
E-Mail: k-kawa@bigfoot.com