Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
