Re: Datatype/ID/IDREF "back to the basic" proposal

[James Clark <jjc@thaiopensource.com>]

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" <kohsuke.kawaguchi@eng.sun.com>
To: "TREX ML" <trex@lists.oasis-open.org>
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                   kohsuke.kawaguchi@eng.sun.com
>
>
>
>