- From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Date: Mon, 12 Apr 2004 09:50:59 -0400
- To: veillard@redhat.com
- Cc: public-xml-id@w3.org
At 8:23 AM -0400 4/12/04, Daniel Veillard wrote: > This also relate to the Issue (id-strictness), in the sense that >a non-validating XML processor would act differently with an ID >attribute declared in the parsed part of the DTD. So we are looking >for feedback on what the community think should happen if the >conditions are not satisfied. I'm in the camp of being strict since >those are new documents, so this should not break existing use, but >this is an open issue. I really wonder if maybe the whole ID-typing (with and without DTDs, with and without schemas, with and without an internal DTD subset, what to do if the schema and the DTD disagree, etc.) isn't maybe too complex to be reasonably resolved? Maybe we need something simpler and more naive. Maybe instead we need to define the behavior and use of xml:id irrespective of types. There seem to be three main use cases, though you can probably think of a few more: 1. XPath and XPath based systems that use the id() selector 2. URI fragment identifiers 3. DOM's getElementByID Would it perhaps be simpler to state that these cases when made xml:id aware first look for an element with an xml:id attribute with a matching value and then look for ID type attributes only if they don't find it? Or perhaps for backwards compatibility reverse that? First look for the ID type attribute and then fallback to xml:id? Advantages: 1. We no longer care what type the xml:id attribute has. We no longer need tom worry about whether the schema or DTD is or is not written, or what to do if there's a conflict. 2. More compatible with existing applications that use ID type attributes with other names and namespaces such as SOAP and XHTML. 3. Easier to explain and teach. Disadvantages: 1. Not perfectly backwards compatible. Still, the behavioral change would be small. For URI fragment identifiers, I don't think the backwards compatibility matters at all. There's just not enough of an installed base here to care about. For XPath and DOM it's trickier, but maybe not too tricky. It just feels to me like the whole type-system is a black hole maybe we shouldn't dive into without considering other alternatives. -- Elliotte Rusty Harold elharo@metalab.unc.edu Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Received on Monday, 12 April 2004 10:10:21 UTC