Re: xml:id

On Jan 9, 2008, at 07:01, Daniel Veillard wrote:
> On Tue, Jan 08, 2008 at 03:25:32AM -0800, Maciej
Stachowiak wrote:
>> On Jan 7, 2008, at 4:18 PM, Timur Mehrvarz wrote:
>>
>>> Are you really suggesting for authors to
duplicate id and xml:id, in
>>> order to cope with this?
>>
>> I can't speak for Henri, but I would suggest
authors use only id in
>> SVG content, and not xml:id, since id is more
compatible and xml:id
>> offers no advantages for publicly deployed web
content.

I'm not sure who "you" in the question referred
to, but I agree with  
Maciej.

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

> and in my opinion it's better to rely on a low level
hardcoded  
> behaviour (basically xml:id is an hardcoded DTD
bypass)
> than one coming from upper layers which are less
generic and  
> sometimes can be conflicting.

I'm suggesting putting the IDness assignment exactly on the
level of  
lowness you'd put the 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. I'm suggesting assigning IDness to id in no
namespace  
(possibly making a grandfathered exception for CML elements)
on the  
level where the xml:id spec specifies assigning IDness to id
in the http://www.w3.or
g/XML/1998/namespace 
. What I'm suggesting is exactly as low or high level as
xml:id.

> and since DTD processing is not guaranteed xml:id
should be the most  
> reliable option.

That's a false dichotomy.

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

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

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/
danielveillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |
virtualization library  http://libvirt.org/