Re: xml:id

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

Received on Wednesday, 9 January 2008 02:25:56 UTC