Here are the reasons I prefer key/keyRef:
1. ID/IDREF is badly designed. It mixes two things (datatyping and
cross-referencing) that are logically separate. It suffers from highly
arbitrary restrictions, such as that ID/IDREFs are names.
2. Using ID/IDREF will create a user expectation that attributes that are
declared in a RELAX NG schema as ID/IDREF will have datatype ID/IDREF in the
infoset (which I don't think will typically be the case). With key/keyRef,
it is clear to users that they are dealing with something different from
ID/IDREF.
3. There's a problem of where to specify the unambiguity constraint. This
is a non-trivial, significant part of the specification. If we use
ID/IDREF, it is hard to put this constraint in the main RELAX NG spec,
because that is supposed to be datatype-independent (although I suppose we
could add builtin id and idref datatypes). On the other hand, it is not
inherent in the semantics of XML Schema ID/IDREF types. The ID/IDREF
constraint seems to fall into a void between the RELAX NG spec and the XML
Schema datatype spec. We clearly will need some guidelines for using XSD
with RELAX NG, but I think these should be simple, obvious things. If we
use the namespace URI of http://www.w3.org/2001/XMLSchema-datatypes, then
our semantics should stick very closely to what is defined by the XML Schema
spec. Otherwise, I think we need to create a datatype vocabulary with its
own namespace URI whose semantics incorporates these guidelines, rather than
using the W3C XML Schema datatypes namespace URI.
4. Sticking to ID/IDREF doesn't save much complexity. The syntactic
complexity added by key/keyRef is minimal: two additional attributes. The
main semantic complexity in key/keyRef is in the unambiguity constraint and
in the assignment of key/keyRef/ID/IDREF-ness to particular nodes; there's
very little difference with ID/IDREF in this respect.
5. The additional functionality is really useful. In particular, multiple
symbol spaces are a very common feature of documents, as are keys that
aren't XML names. The absence of these features often forces users to adopt
inconvenient and redundant markup. Instead of
simply
<termref>some term</termref>
...
<termdef term="some term">...</termdef>
you have something like:
<termref ref="dt-some-term">some term</termref>
...
<termdef id="dt-some-term" term="some term">...</termdef>
I really don't want to have to do this sort of thing any more.
James
----- Original Message -----
From: "Kohsuke KAWAGUCHI" <>
To: "TREX ML" <>
Sent: Saturday, May 19, 2001 1:48 AM
Subject: Datatype/ID/IDREF "back to the basic" proposal
>
> For the record ...
>
> Let me explain what I proposed in the last conference call.
>
>
>
> My proposal doesn't introduce any new primitive in RELAX NG.
>
> The only addition is a constraint that ensures we can use XML1.0's plain
> vanilla ID/IDREF (and IDREFS) types. The constraint itself is posted by
> jjc and is anyway necessary whichever proposal we adopt.
>
>
> Cons
> ----
> - lack of feature. No typed key, no scoped key.
> What you get is the same functionality as what we have now with DTD.
>
>
> Pros
> ----
> - Simplicity and minimum impact to the current TREX syntax.
> Thereby reducing the "time to market".
>
> This constraint doesn't have to be in the core spec. It's just a
> guideline when RELAX NG is used with XSD.
>
>
> --
> Kohsuke KAWAGUCHI +1 650 786 0721
> Sun Microsystems
>
>
>
>
