[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Re: determining ID-ness in XML
- From: David Brownell <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 01 Nov 2001 12:19:11 -0800
> 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.