Re: xml:id

On Jan 9, 2008, at 16:05, Daniel Veillard wrote:

> 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.

Norman Walsh's implementation is a SAX filter outside the XML  
processor. (My IDness assignment implementation is a SAX filter as  
well.) The formulation of xml:id processing using the notion of an  
xml:id Processor as a "software module that works in conjunction with  
an XML processor" supports the view that xml:id doesn't redefine the  
XML layer but adds a processing layer on top of it. Even if this  
processing layer is above the namespace layer, the namespace spec  
makes the "xml" prefix mapping hard-wired, so to order of xml:id and  
namespace processing don't make a practical difference.

>> 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 ?

I'm suggesting that any application that wants to perform ID-sensitive  
operations on XHTML, SVG or MathML (or in the future XBL2) documents  
retrieved from the Web without a bilateral agreement with the document  
author about xml:id use has to and will have to treat the id attribute  
in no namespace as an attribute that participates in those operations.

> [...]
>>> 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.

Generic tools could add a processing layer for assigning IDness to id  
in no namespace. (Implementations that don't report duplicate IDs and/ 
or that don't support CML can probably even ignore the CML  
grandfathering issue.)

> 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 an implementation doesn't report duplicate IDs, it can probably get  
away with not knowing about particular vocabularies and  
unconditionally assigning IDness to id in no namespace.

> 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 !


What itches me is introducing the 'xml:' prefix so late that it cannot  
be used exclusively due to backwards compatibility issues. When it  
cannot be used exclusively, it doesn't solve a problem but only makes  
it more complex.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 9 January 2008 15:03:46 UTC