Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

* Tim Bray wrote:
>On Nov 19, 2004, at 4:13 PM, Bjoern Hoehrmann wrote:
>
>> You miss that this has an impact on general purpose XML processing,
>> fragment identifiers are highly relevant to XML Linking for which
>> an often cited use case is link recognition in unknown XML formats
>> for link checkers and search engines.
>
>No.  In all cases of which I'm aware, data on the web that's served as 
>*/xml is a symptom of a bug, and it is not OK for agents, web robots or 
>any other kind, to infer #fragid rules.

http://www.w3.org/TR/xslt#section-Embedding-Stylesheets seems to imply
that applications are even expected to do exactly that...

>On the other hand, I could be wrong.  If there is a good use case for 
>serving something as */xml and expecting intelligent behavior with 
>respect to #fragid's, let's hear it.

There is a good use case here, support for the +xml is rather poor for
general purpose XML tools, most of them either ignore the MIME Type or
support only a limited/empty set of them even though they support */xml.
But this is not really relevant here, you forget that this also applies
to */*+xml, if there is no specification that defines what #foo refers
to for unknown +xml types, implementations cannot do anything useful
with such references, they would need a constantly updated list of hard-
coded types for that which is not very usable.

Further problems would arise in the context of compound documents,
if FooML and BarML have different rules for what #foo refers to,
implementation of it for a FooML+BarML document would probably be
difficult (depending on the rules), worse if you have a XHTML+SVG+
XForms+MathML+SMIL+sXBL+RDF document (which is not unlikely).

Received on Saturday, 20 November 2004 22:25:32 UTC