- From: Daniel Veillard <veillard@redhat.com>
- Date: Sat, 11 Jun 2005 05:11:50 -0400
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Dan Connolly <connolly@w3.org>, public-xml-id@w3.org
On Sat, Jun 11, 2005 at 12:44:58AM +0200, Bjoern Hoehrmann wrote: > * Daniel Veillard wrote: > >On Fri, Jun 10, 2005 at 11:11:34PM +0200, Bjoern Hoehrmann wrote: > >> could you please state whether adding text like > >> > >> If an implementation supports CSS 2.1 and also supports > >> xml:id, then the xml:id attribute must be treated as an > >> ID for the purposes of CSS selector processing. > >> > >> to CSS 2.1 would in some way change conformance requirements for > >> implementations that support CSS 2.1 and also support xml:id? If > >> it does, could you please clarify why and why xml:id does not > >> contain a conformance requirement to this effect already? > > > >xml:id is basically a parser feature. I really don't see why it should > >add conformance statement for all the specs which may depend on XML. > > I asked what happens if the text above is added to CSS 2.1, I did not > suggest to include such text in xml:id or CSS 2.1. I will draw it for > you: Okay, sorry, then it was a misunderstanding from my part, I probably took the quote out of context. > Some people apparently think we currently have a) > > +----------------------+ +-----------------------+ > | xml:id ID Assignment | <huge gap here> | CSS Selector Matching | > +----------------------+ +-----------------------+ > > And want to fix it with b) > > +----------------------+ +-----------------------+ > | xml:id ID Assignment +-----------------+ CSS Selector Matching | > +----------------------| If an implement |-----------------------+ > | ation supports | > | CSS 2.1 and als | > | o supports xml: | > | id, then ... | > +-----------------+ > > In my opinion it's more reasonable to have c) > > +----------------------+-----------------------+ > | xml:id ID Assignment | CSS Selector Matching | > +----------------------+-----------------------+ > > So I basically asked why we have a) and not c) at the moment. To me the problem (for the integration of xml:id) is rather to match what are descriptions in pure conceptual models of Infoset and XPath datamodel, into terms that will be understood without doubts by the people using the software. At the lower layer we have those notions of attribute type at the DTD level, at the Schemas level, which are presented in relatively abstract ways, the Infoset being the most abstract one, plus there is 2 notions of IDness in the Infoset. Then on top of that what developpers on higher layers really see are the XPath, DOM, CSS, and toolkit ID related APIs or selectors. What I see from the report of users is confusion, especially when they expected their ID to work and don't actually (missing ID declaration, or external subset not parsed, etc...) or worse it doesn't work reliably. So yes I fully agree with you we need to remove the magical gap between instanciation of ID and them working reliably from an user point of view, it's really what xml:id is all about in my opinion. thanks ! Daniel -- Daniel Veillard | Red Hat Desktop team http://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 Saturday, 11 June 2005 09:12:04 UTC