- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 20 Nov 2004 23:24:57 +0100
- To: Tim Bray <tbray@textuality.com>
- Cc: www-tag@w3.org
* 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