[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ID/IDREF strawman
> > - 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 > > Does it implies "01" is not equal to "1" even when I use integer as the > type of key/keyref? Good question. I was imagining that keys would be compared depending on the datatypes declared in the content. That's going to be complicated if the content is not a single <data> element. > This problem also introduces another problem of how > to handle whitespaces. Yes. When we have a datatype, the whitespace issue should be handled by the datatype. Otherwise I guess we need to allow the whiteSpace attribute to be specified. > > - the content pattern must not allow elements or attributes > > So > > <key name="id"> > <choice> > <data type="xsd:integer" /> > <data type="xsd:string" /> > </choice> > </key> > > Is this allowed? If we do that then we get into comparing constants of different datatypes, which I would rather avoid. Another issue is that XML Schema has a first match semantics for union. And what about <key name="id'> <xsd:union baseTypes="xsd:integer xsd:string" trex:role="datatype"/> </key> ? We need to think more about the interface between TREX and an external datatyping system. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC