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

?  We need to think more about the interface between TREX and an external
datatyping system.


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

Powered by eList eXpress LLC