Re: xml:id

[Timur Mehrvarz]

I'm forwarding this message I received from Eric Seidel a few days  
back. Their decision makes me a uncomfortable. People can use xml:id  
in their XHTML+SVG content and be compliant with one browser,  
currently. Or they can use id without xml: and be compliant with 3  
browsers. But not with the SVG Tiny 1.2 spec. Or am I missing something?

Timur

On 28.12.2007, at 07:45, Eric Seidel wrote:

> After some discussion in #webkit, we've decided against implementing  
> xml:id:
>
> http://bugs.webkit.org/show_bug.cgi?id=16505
>
> xml:id has proven pretty irrelevant on the web so far (I can't think  
> of a single page which actually uses it).  It provides little-to-no  
> benefit over "id" as specified by SVG and HTML and just adds more  
> unnecessary complexity to WebKit.
>
> I would recommend that WICD consider removing xml:id from their list  
> of requirements ...
>>
>
> Certainly if there was a major shift in the web and real websites  
> actually started to use xml:id, or there was a demonstrable benefit  
> to its support in WebKit, we'd reconsider.
>
> -eric

[Anne van Kesteren-2]

On Thu, 03 Jan 2008 20:35:21 +0100, Timur Mehrvarz <timur.mehrvarz@...>  
wrote:
> I'm forwarding this message I received from Eric Seidel a few days back.  
> Their decision makes me a uncomfortable. People can use xml:id in their  
> XHTML+SVG content and be compliant with one browser, currently. Or they  
> can use id without xml: and be compliant with 3 browsers. But not with  
> the SVG Tiny 1.2 spec. Or am I missing something?

I very much concur with the WebKit team that SVG should not replace id="",  
which already works, with xml:id="". (Despite the fact that we implemented  
xml:id support of some sorts.)


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Doug Schepers-3]

Hi, Anne-

Anne van Kesteren wrote (on 1/3/08 5:23 PM):

>
> On Thu, 03 Jan 2008 20:35:21 +0100, Timur Mehrvarz
> <timur.mehrvarz@...> wrote:
>> I'm forwarding this message I received from Eric Seidel a few days
>> back. Their decision makes me a uncomfortable. People can use xml:id
>> in their XHTML+SVG content and be compliant with one browser,
>> currently. Or they can use id without xml: and be compliant with 3
>> browsers. But not with the SVG Tiny 1.2 spec. Or am I missing something?
>
> I very much concur with the WebKit team that SVG should not replace
> id="", which already works, with xml:id="". (Despite the fact that we
> implemented xml:id support of some sorts.)

Are you speaking for yourself or Opera?  You seem to imply you're
speaking for Opera by your use of "we".

Thanks for the clarification.

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

[distobj]

On 1/3/08, Anne van Kesteren <annevk@...> wrote:

>
> On Thu, 03 Jan 2008 20:35:21 +0100, Timur Mehrvarz <timur.mehrvarz@...>
> wrote:
> > I'm forwarding this message I received from Eric Seidel a few days back.
> > Their decision makes me a uncomfortable. People can use xml:id in their
> > XHTML+SVG content and be compliant with one browser, currently. Or they
> > can use id without xml: and be compliant with 3 browsers. But not with
> > the SVG Tiny 1.2 spec. Or am I missing something?
>
> I very much concur with the WebKit team that SVG should not replace id="",
> which already works, with xml:id="". (Despite the fact that we implemented
> xml:id support of some sorts.)

+1

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

[Maciej Stachowiak]

SVG Tiny 1.2 allows both I'd and xml:id, so content using it is  
conforming.



On Jan 3, 2008, at 11:35 AM, Timur Mehrvarz <timur.mehrvarz@...>  
wrote:

>
> I'm forwarding this message I received from Eric Seidel a few days  
> back. Their decision makes me a uncomfortable. People can use xml:id  
> in their XHTML+SVG content and be compliant with one browser,  
> currently. Or they can use id without xml: and be compliant with 3  
> browsers. But not with the SVG Tiny 1.2 spec. Or am I missing  
> something?
>
> Timur
>
> On 28.12.2007, at 07:45, Eric Seidel wrote:
>
>> After some discussion in #webkit, we've decided against  
>> implementing xml:id:
>>
>> http://bugs.webkit.org/show_bug.cgi?id=16505
>>
>> xml:id has proven pretty irrelevant on the web so far (I can't  
>> think of a single page which actually uses it).  It provides little-
>> to-no benefit over "id" as specified by SVG and HTML and just adds  
>> more unnecessary complexity to WebKit.
>>
>> I would recommend that WICD consider removing xml:id from their  
>> list of requirements ...
>>>
>>
>> Certainly if there was a major shift in the web and real websites  
>> actually started to use xml:id, or there was a demonstrable benefit  
>> to its support in WebKit, we'd reconsider.
>>
>> -eric
>
>

[Henri Sivonen]

On Jan 4, 2008, at 04:41, Maciej Stachowiak wrote:

> SVG Tiny 1.2 allows both I'd and xml:id, so content using it is  
> conforming.


SVG Tiny 1.2 is actually worse than just allowing both id and xml:id.  
SVG Tiny 1.2 makes the IDness of id conditional depending on the  
presence of xml:id. I think this is a very bad idea and id should be  
unconditionally an ID.
http://lists.w3.org/Archives/Public/www-svg/2007Oct/0086.html

More generally, for deployed Web XML languages (XHTML, SVG and MathML)  
xml:id is a feature with a cost but no payoff. Browsers will have to  
continue to support ID semantics for the id attribute in no namespace  
on XHTML, SVG and MathML attributes forever. Thus, xml:id can only add  
complexity--not remove it. When the IDness of id has to be supported  
anyway, xml:id does not add any functionality--it is additional  
complexity with no upside in the Web context.

Now, one might argue that xml:id is beneficial for generic XML  
processing like making the XPath id() function work with generic XML.  
However, the xml:id spec doesn't merely by existing make pre-existing  
XPath implementations support xml:id. Instead, you have to add an  
xml:id Processor between the XML processor (aka. XML parser) and the  
XPath implementation.

The better way to solve the non-Web XML processing problem would be to  
add a filter that assigns IDness to id instead of an xml:id Processor  
in the pipeline.

I have implemented such a filter *and* an xml:id Processor. In my  
experience, implementing a filter that assigns IDness to to id is  
simpler than implementing an xml:id Processor. (An xml:id Processor is  
required to perform additional, in my opinion, rather useless  
operations.)

Validator.nu uses XPath-based Schematron to implement part of HTML5  
and XHTML5 conformance checking. To make this work on the HTML5 side,  
the HTML5 parser assigns IDness to id. To make this work on the XHTML5  
side, there's the aforementioned filter that assigns IDness to id. It  
works.

Now, one might argue that it is horribly wrong to assign IDness to id  
without DTD processing or to always assign it regardless of the  
element that the attribute is on, because someone out there might have  
an XML vocabulary where the attribute id in no namespace does not have  
IDness. The argument of wrongness of ID assignment in the absence of a  
DTD is without merit: Assigning IDness without a DTD is exactly what  
xml:id does! Moreover, for practical observability like getElementById  
or the CSS # selector, browsers have to implement de facto IDness for  
the id attribute in no namespace for Web XML languages.

The argument that someone out there might have an XML language that  
has an id without IDness is not without merit but is still a mere  
distraction. After I deployed the unconditional IDness assignment in  
Validator.nu, I got a bug report that Validator.nu, which is used as  
the back end of a CML validator (http://cmlcomp.org/validator/) was  
wrongly complaining about duplicate id attribute values in CML. So  
yes, it is true that there exists at least one XML language where id  
is not an ID.

Yet, the existence of a CML as a counter example refuting the  
assumption that id is always an ID is utterly irrelevant to what to do  
with deployed Web languages (XHTML, SVG and MathML) or known-as-
upcoming Web languages (XBL2). For an app like Validator.nu, it is  
clear that assigning IDness to id on XHTML, SVG, MathML or XBL2  
elements is desirable and on CML elements undesirable. What to do with  
known languages isn't the question. The question really is what to do  
with unknowns. I currently err on the side of assigning IDness for the  
unknowns.

But even this is irrelevant to browsers as long as they don't support  
CML. Browsers could unconditionally assign IDness to id without  
creating real problems. And at that point, xml:id offers no additional  
value--just cost.

P.S. I think making id non-ID is a design bug in CML. Calling the  
attribute 'name' would be more consistent with XML design patterns,  
but second-guessing CML is pointless and it should just be considered  
grandfathered.

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

[Timur Mehrvarz]

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?
Thank you.

Timur

On 04.01.2008, at 11:14, Henri Sivonen wrote:

> On Jan 4, 2008, at 04:41, Maciej Stachowiak wrote:
>
>> SVG Tiny 1.2 allows both I'd and xml:id, so content using it is  
>> conforming.
>
>
> SVG Tiny 1.2 is actually worse than just allowing both id and  
> xml:id. SVG Tiny 1.2 makes the IDness of id conditional depending on  
> the presence of xml:id. I think this is a very bad idea and id  
> should be unconditionally an ID.
> http://lists.w3.org/Archives/Public/www-svg/2007Oct/0086.html
>
> More generally, for deployed Web XML languages (XHTML, SVG and  
> MathML) xml:id is a feature with a cost but no payoff. Browsers will  
> have to continue to support ID semantics for the id attribute in no  
> namespace on XHTML, SVG and MathML attributes forever. Thus, xml:id  
> can only add complexity--not remove it. When the IDness of id has to  
> be supported anyway, xml:id does not add any functionality--it is  
> additional complexity with no upside in the Web context.
>
> Now, one might argue that xml:id is beneficial for generic XML  
> processing like making the XPath id() function work with generic  
> XML. However, the xml:id spec doesn't merely by existing make pre-
> existing XPath implementations support xml:id. Instead, you have to  
> add an xml:id Processor between the XML processor (aka. XML parser)  
> and the XPath implementation.
>
> The better way to solve the non-Web XML processing problem would be  
> to add a filter that assigns IDness to id instead of an xml:id  
> Processor in the pipeline.
>
> I have implemented such a filter *and* an xml:id Processor. In my  
> experience, implementing a filter that assigns IDness to to id is  
> simpler than implementing an xml:id Processor. (An xml:id Processor  
> is required to perform additional, in my opinion, rather useless  
> operations.)
>
> Validator.nu uses XPath-based Schematron to implement part of HTML5  
> and XHTML5 conformance checking. To make this work on the HTML5  
> side, the HTML5 parser assigns IDness to id. To make this work on  
> the XHTML5 side, there's the aforementioned filter that assigns  
> IDness to id. It works.
>
> Now, one might argue that it is horribly wrong to assign IDness to  
> id without DTD processing or to always assign it regardless of the  
> element that the attribute is on, because someone out there might  
> have an XML vocabulary where the attribute id in no namespace does  
> not have IDness. The argument of wrongness of ID assignment in the  
> absence of a DTD is without merit: Assigning IDness without a DTD is  
> exactly what xml:id does! Moreover, for practical observability like  
> getElementById or the CSS # selector, browsers have to implement de  
> facto IDness for the id attribute in no namespace for Web XML  
> languages.
>
> The argument that someone out there might have an XML language that  
> has an id without IDness is not without merit but is still a mere  
> distraction. After I deployed the unconditional IDness assignment in  
> Validator.nu, I got a bug report that Validator.nu, which is used as  
> the back end of a CML validator (http://cmlcomp.org/validator/) was  
> wrongly complaining about duplicate id attribute values in CML. So  
> yes, it is true that there exists at least one XML language where id  
> is not an ID.
>
> Yet, the existence of a CML as a counter example refuting the  
> assumption that id is always an ID is utterly irrelevant to what to  
> do with deployed Web languages (XHTML, SVG and MathML) or known-as-
> upcoming Web languages (XBL2). For an app like Validator.nu, it is  
> clear that assigning IDness to id on XHTML, SVG, MathML or XBL2  
> elements is desirable and on CML elements undesirable. What to do  
> with known languages isn't the question. The question really is what  
> to do with unknowns. I currently err on the side of assigning IDness  
> for the unknowns.
>
> But even this is irrelevant to browsers as long as they don't  
> support CML. Browsers could unconditionally assign IDness to id  
> without creating real problems. And at that point, xml:id offers no  
> additional value--just cost.
>
> P.S. I think making id non-ID is a design bug in CML. Calling the  
> attribute 'name' would be more consistent with XML design patterns,  
> but second-guessing CML is pointless and it should just be  
> considered grandfathered.
>
> --
> Henri Sivonen
> hsivonen@...
> http://hsivonen.iki.fi/
>
>

[Maciej Stachowiak]

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.

Regards,
Maciej

>
> Thank you.
>
> Timur
>
> On 04.01.2008, at 11:14, Henri Sivonen wrote:
>
>> On Jan 4, 2008, at 04:41, Maciej Stachowiak wrote:
>>
>>> SVG Tiny 1.2 allows both I'd and xml:id, so content using it is  
>>> conforming.
>>
>>
>> SVG Tiny 1.2 is actually worse than just allowing both id and  
>> xml:id. SVG Tiny 1.2 makes the IDness of id conditional depending  
>> on the presence of xml:id. I think this is a very bad idea and id  
>> should be unconditionally an ID.
>> http://lists.w3.org/Archives/Public/www-svg/2007Oct/0086.html
>>
>> More generally, for deployed Web XML languages (XHTML, SVG and  
>> MathML) xml:id is a feature with a cost but no payoff. Browsers  
>> will have to continue to support ID semantics for the id attribute  
>> in no namespace on XHTML, SVG and MathML attributes forever. Thus,  
>> xml:id can only add complexity--not remove it. When the IDness of  
>> id has to be supported anyway, xml:id does not add any  
>> functionality--it is additional complexity with no upside in the  
>> Web context.
>>
>> Now, one might argue that xml:id is beneficial for generic XML  
>> processing like making the XPath id() function work with generic  
>> XML. However, the xml:id spec doesn't merely by existing make pre-
>> existing XPath implementations support xml:id. Instead, you have to  
>> add an xml:id Processor between the XML processor (aka. XML parser)  
>> and the XPath implementation.
>>
>> The better way to solve the non-Web XML processing problem would be  
>> to add a filter that assigns IDness to id instead of an xml:id  
>> Processor in the pipeline.
>>
>> I have implemented such a filter *and* an xml:id Processor. In my  
>> experience, implementing a filter that assigns IDness to to id is  
>> simpler than implementing an xml:id Processor. (An xml:id Processor  
>> is required to perform additional, in my opinion, rather useless  
>> operations.)
>>
>> Validator.nu uses XPath-based Schematron to implement part of HTML5  
>> and XHTML5 conformance checking. To make this work on the HTML5  
>> side, the HTML5 parser assigns IDness to id. To make this work on  
>> the XHTML5 side, there's the aforementioned filter that assigns  
>> IDness to id. It works.
>>
>> Now, one might argue that it is horribly wrong to assign IDness to  
>> id without DTD processing or to always assign it regardless of the  
>> element that the attribute is on, because someone out there might  
>> have an XML vocabulary where the attribute id in no namespace does  
>> not have IDness. The argument of wrongness of ID assignment in the  
>> absence of a DTD is without merit: Assigning IDness without a DTD  
>> is exactly what xml:id does! Moreover, for practical observability  
>> like getElementById or the CSS # selector, browsers have to  
>> implement de facto IDness for the id attribute in no namespace for  
>> Web XML languages.
>>
>> The argument that someone out there might have an XML language that  
>> has an id without IDness is not without merit but is still a mere  
>> distraction. After I deployed the unconditional IDness assignment  
>> in Validator.nu, I got a bug report that Validator.nu, which is  
>> used as the back end of a CML validator (http://cmlcomp.org/validator/ 
>> ) was wrongly complaining about duplicate id attribute values in  
>> CML. So yes, it is true that there exists at least one XML language  
>> where id is not an ID.
>>
>> Yet, the existence of a CML as a counter example refuting the  
>> assumption that id is always an ID is utterly irrelevant to what to  
>> do with deployed Web languages (XHTML, SVG and MathML) or known-as-
>> upcoming Web languages (XBL2). For an app like Validator.nu, it is  
>> clear that assigning IDness to id on XHTML, SVG, MathML or XBL2  
>> elements is desirable and on CML elements undesirable. What to do  
>> with known languages isn't the question. The question really is  
>> what to do with unknowns. I currently err on the side of assigning  
>> IDness for the unknowns.
>>
>> But even this is irrelevant to browsers as long as they don't  
>> support CML. Browsers could unconditionally assign IDness to id  
>> without creating real problems. And at that point, xml:id offers no  
>> additional value--just cost.
>>
>> P.S. I think making id non-ID is a design bug in CML. Calling the  
>> attribute 'name' would be more consistent with XML design patterns,  
>> but second-guessing CML is pointless and it should just be  
>> considered grandfathered.
>>
>> --
>> Henri Sivonen
>> hsivonen@...
>> http://hsivonen.iki.fi/
>>
>>
>

[Daniel Veillard-2]

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

[Anne van Kesteren-2]

On Wed, 09 Jan 2008 06:01:18 +0100, Daniel Veillard <daniel@...>  
wrote:
> 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.

I fail to see how this matters for SVG, (X)HTML, MathML, or XBL content  
for that matter as these markup languages all include an id="" attribute  
that behaves in the same way. User agents processing those languages need  
to be aware of way more than the IDness of the id="" attribute.

Now for Web browsers it would have made things better if the id=""  
attribute were made a global attribute in XML as opposed to xml:id  
(considering the primary authoring language uses that and all), but it  
seems unlikely that this error will be fixed with xml:id in place.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Henri Sivonen]

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.org/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
hsivonen@...
http://hsivonen.iki.fi/

[Daniel Veillard-2]

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

[Henri Sivonen]

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@...
http://hsivonen.iki.fi/