Re: Missing "else" in section 4.3

On Mon, Apr 12, 2004 at 09:50:59AM -0400, Elliotte Rusty Harold wrote:
> 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?

1/ and 2/ are the same. Fragment identifier be it #foo and #xpointer(id('foo'))
are defined in terms of XPath data model ID lookup. I assume it's the same
for DOM too, except they are based on a different data model but using
type for recognition.

Matching value means modifying XPath and DOM spec since this is no more
a modification of the Infoset/XPath data model and instead a change in
the implementation of those upper layers. You may suggest this
approach, I don't think it will be doable in any reasonable timeframe.
The goal is precisely to not have to change the other specs.

> Or perhaps for backwards compatibility reverse that? 
> First look for the ID type attribute and then fallback to xml:id?

Same problem, you need to change the full set of specs, err, no thanks...

> It just feels to me like the whole type-system is a black hole maybe 
> we shouldn't dive into without considering other alternatives.

If the alternatives forces to regenerate new revision of all the specs
using IDness, don't think they will get enough traction to ever complete.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Received on Monday, 12 April 2004 12:04:48 UTC