RE: [opendocument-users] RE: office-comment text:id vs xml:id (ODF 1.2CD01)

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Rick,

Thanks for the analysis.  That clarifies a lot.  

I think the situation we are in is that there is an attempt to accomplish
(3) or (4) on your list, but no effort to reconcile the uniqueness
constraints, referential integrity, and what permissible references to
particular "ids" are in the ODF document structure.

My personal preference is for (3), keeping xml:id as the known ID for use as
a fragment identifier that can be relied upon in URIs and some feature that
needs to do that can count on using an xml:id if it is there or inserting an
xml:id if it isn't, without interfering with any other referential integrity
constraints that may subsist in the ODF document model.

But the greater challenge is knowing what the uniqueness and referential
integrity constraints are that are currently tacit and inexplicable in the
ODF specification.  Without that, I don't think we know how to establish a
specified behavior and make a sane and safe choice, whichever the case is.
There is no way to reliably figure this out from the specification so we are
going to have to do some implementation spelunking.

I also think we need to be more serious about down-level compatibility as
well as upward compatibility, in the 1.x progression.

Sounds like an over-constrained problem and one that I have no insight into,
having no ODF implementation to support.

 - Dennis

-----Original Message-----
From: rjelliffe@allette.com.au [mailto:rjelliffe@allette.com.au]
http://lists.oasis-open.org/archives/opendocument-users/200903/msg00026.html

Sent: Sunday, March 08, 2009 21:16
To: 'ODF Users List'
Subject: RE: [opendocument-users] RE: office-comment text:id vs xml:id (ODF
1.2CD01)

[ ... ]

The point is that RELAX NG, XML Schemas and DTDs all only provide very
simple ID systems. It should not be a surprise to anyone that they run out
of steam very early. They are not designed to be anything other than 80/20
solutions.

Very simple Schematron schemas can allow declaration and validation of
almost any kind of complex ID/IDREF constraints: a 99/1 solution.

So here are some approaches that the ODF WG could take is to say that an
element with both an old ID attribute and an xml:id should have the same
value in both, and:

1) Use xs:NCName for all IDs. Then make a Schematron schema for the
uniqueness constraints.

2) Use xs:ID for all existing IDs, and xs:NCName for all new attributes
such as xml:ID.  Then make a Schematron schema for the uniqueness
constraints.

3) Use an xs:ID for all xml:IDs, and xs:NCName for all old ids. Then make
a Schematron schema for the uniqueness constraints.

4) Use an xs:ID for all xml:IDs and for existing IDs on other elements,
and xs:NCName for superceded ids. Then make a Schematron schema for the
uniqueness constraints.

I don't know that any of these choices is particularly better than
another. Probably people would be most comfortable with 4), because it
provides the best declarations for a databinding tool might use.

Cheers
Rick Jelliffe

[ ... ]