Re: xml:id

On Wed, Jan 09, 2008 at 12:07:14PM +0200, Henri Sivonen wrote:
> On Jan 9, 2008, at 07:01, Daniel Veillard wrote:
> >Do SVG implementation actually parse/handle the DTD embedded in Web
> >documents ?
> 
> They don't generally.
[...]
> >I doubt it, in that case you rely on hardcoded behaviour of the  
> >engine,
> 
> You don't need to rely on SVG engine-level hardcoding if you move the  
> hardcoding layer (at least conceptually) to between the XML processor  
> and the DOM builder. After all, that's were you'd put an xml:id  
> Processor.
[...]
> >What you are suggesting may be better from a code behaviour  
> >viewpoint *now* but from an user data point of view,
> >generic processing, long term management of those, it sounds safer  
> >to use an ID handled at the XML level,
> 
> xml:id isn't on the XML level. It is immediately on one level above  
> the XML level.

Hum, strange that's not the case in my implementation, xml:id
is handled as if an internal subset had defined it as being of type ID
in the XML document, it's XML level, really. The best proof is that
it uses an 'xml' hardcoded prefix, it's below namespaces in practice.

>I'm suggesting assigning IDness to id in no namespace  

You are suggesting only specific tools can process the data customers will
put on the web ?

[...]
> >There is certainly Web engine which don't recognize xml:id now, but  
> >if the web content is targetting reuse and long lifetime I would  
> >avoid relying just on the SVG hardcoded behaviour.
> 
> Considering long life time, browsers can never stop supporting the  
> IDness of id in no namespace on XHTML, MathML and SVG elements.

  Must be a yes to the previous question ... Well it is also sometimes
useful to extract data with generic tools, to automate processing.
I guess it all comes back from the original XML example of including data
in Web pages and still be able to extract them as non-rendered content
useful for a wide variety of applications, not necessarilly a dedicated
fat engine with hardcoded knowledge of a set of vocabularies. If it's
the 'xml:' prefix which really itches you, I somehow understand your
fear of namesapce, but really this is just syntactic sugar in that case
and that reaction should really not lead to a specialization of tools
to process the customer data, it's really not worth it !

  I certainly don't want to reopen a flamefest. Maybe xml:id 
doesn't suit your needs, I just hope it will be reviewed
with an honnest perspective.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

Received on Wednesday, 9 January 2008 14:04:19 UTC