Re: [xml-dev] Re: determining ID-ness in XML

[David Brownell <david-b@pacbell.net>]

>       If the IDness
> of attributes is defined in a DTD then having the instance define this
> property too open wide the door to an array of problems due to the
> conflicts between the DTD and the instance:

Hence my initial enthusiasm for an xml:id-ish solution, if one could
be found that didn't mandate only one ID per element.  (There can be
many reasons to label a node; one-label-per-node restrictions are
trouble when labels get very much use.)  Maybe "xml:ids".


>   It may take quite a bit of time before finding and making decisions
> for all the corner cases associated to an indirect IDness mechanism.

Where the indirection was the "list the ID attributes in the instance"
(the xml:idatts approach) ... a related issue is that such mechanisms
are error prone.  They can work, if everyone agrees.


> If people don't want to do validation, then xml:id should be used, but
> if the document was authored with a DTD in mind, using an indirection
> mechanism to try to bypass the author intent doesn't seems to me to be
> an improvement, quite the opposite. 

I think that's mixing several things up.  "Wanting to do validation" is a
policy issue, unrelated to author intent, just like "wanting to avoid
reading the external subset".  Having a DTD is orthogonal to those,
and is more akin to author intent -- but isn't the same as wanting
to identify particular nodes by name/role (rather than the less stable
notion of "position" or, as Len said, "address").

I think the problem is needing stable node identifiers (by name/role)
that don't force document authors to declare them in internal subsets
(or use Schema-du-jour) to ensure that minimally conformant XML
parsers will see the decls.  So the question becomes where they get
identified.  A "global" definition, like an "xml:ids" attribute, seems to
be the least invasive/error-prone solution yet proposed.

- Dave