> > - 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
