Re: xml:id

On Tue, Jan 08, 2008 at 03:25:32AM -0800, Maciej Stachowiak wrote:
> 
> 
> On Jan 7, 2008, at 4:18 PM, Timur Mehrvarz wrote:
> 
> >Hello, we have a bit of controversy around xml:id. A link to a  
> >previous post of mine:
> >http://lists.w3.org/Archives/Public/public-cdf/2008Jan/0000.html
> >
> >Apparently related to this:
> >http://lists.w3.org/Archives/Public/www-svg/2007Oct/0113.html
> >
> >Situation is, that some of our test cases fail, if xml:id is not  
> >supported for SVG content:
> >http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml#mobile10-2
> >
> >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.

  Hi Maciej,

Do SVG implementation actually parse/handle the DTD embedded in Web
documents ? I doubt it, in that case you rely on hardcoded behaviour 
of the engine, 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. 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, and since DTD processing is 
not guaranteed xml:id should be the most reliable option.
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.

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 05:00:18 UTC