Re: ID/IDREF strawman #2

[James Clark <jjc@jclark.com>]

> >    <anyString keyRef="whatever"/>
>
> @keyRef should be also used with <data/>. In this way, we can forget
> about white spaces. I don't see any reason to allow key/keyref to
> <anyString/>.

I agree key/keyRef on anyString is not satisfactory. However, at the moment,
TREX is quite useable without any external datatypes at all (at least for
simple document applications).   I would like to preserve this property.  We
could make @type on data optional when you have a key or keyRef attribute.

<data keyRef="whatever"/>

or TREX could provide two builtin types: string and tokens

<data keyRef="whatever" type="string"/>

> > This would present a problem with anonymous datatypes.
>
> I think there are two options:
>
> #1: prohibit anonymous datatypes (as Murata-san said). This can be
> achieved for any datatype vocabulary by restricting use of @key/@keyref
> to <data/> element only. This makes it easy to check the equality of the
> type: key/keyref that share the same symbol space must have the same
> type name.
>
> #2: if we want to use anonymous types with key/keyref, then we have to
> rely on datatype library to test equality of two types, which probably
> causes interoperability problem. Some library may
> consider "byte" type and "integer" type as "compatible", whereas others
> may not.
>
> I think option #1 is better and easier.

I agree #2 is problematic.  Also since anonymous types allow union, then you
get into comparing values of distinct datatypes.  On the other hand #1 is
not quite satisfactory: saying that you can't have restrictions eg (a
maximum length of 8) and key/keyRef checking at the same time doesn't seem
like a good design to me.

I am starting to feel that the anonymous datatypes facility is not quite
right, and that we need to move to relying on the external datatype system
purely for the collection of builtin datatypes and the facets, and the
syntax should be defined in TREX. I am going to work on a proposal for this.

James