Re: Missing "else" in section 4.3

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