Elephant startled by Mouse

Related link: http://www.ietf.org/rfc/rfc3987.txt

xml:include

Interesting "http://weblogs.asp.net/cazzu/archive/2005/01/10/XsdAndXInclude.aspx"
>discussions this week that
xml:include is incompatible with typical XML Schemas,
because it may add xml:lang attributes and so on.
Or, at least, that inclusion might have to take place
after schema validation.

For prose, language is a fundamental facet, that needs
to be set in the instance. But database vendors really don't like this idea: it is unworkable to have to allow the possibility that every text field may need a language property. I don't see how the contradictory requirements between prose and DBMS can be reconciled.

Internationalized Resource Identifiers (IRIs)

W3C has announced it will support the recent RFC 3987 for IRIs. IRIs are the IETF (Internet Engineering Task Force) officially saying how to support non-ASCII characters in URIs.

All this almost eight years after XML allowed you to type any characters as SYSTEM identifiers for entities! The internationalization wheels move very slowly at IETF, witness the time taken for Internationalized Domain Names.

Congrats to the indefatigable Martin Dürst and M. Suignard, and everyone involved.

xml:id

This W3C Candidate Recommendation supposedly brings us one step closer to not needing DTDs. But actually it brings us one step closer to not needing XML Schemas either, by the same logic.

I see two big issues that keep DTDs around. The first is of course entities: Norm Walsh had a good post on XML-DEV this week outlining various options for handling entities without DTDs, and I was glad to see the option I favour mentioned: to build the standard ISO and MathML entities into XML itself.

The second issue is the issue of processing model. At the moment there are a lot of XML-related specs floating around in various stages of undress: xmlink, xml:id, xml:include, and so on. But often they cannot be useful for much public use unless you know that the the other end will handle them, which you don't. They are schema-level apparatus not transparent-infrastructure-level. You can use an entity in XML because you know the other end will handle them (or fail): you know what the infoset your are sending it. Use xml:include, xml:id, even XML Schemas and you have no idea what a blind receiver ends up seeing.

I suspect W3C groups are laying these eggs knowing they are useless for public data exchange, but to have them available for a future consolidation of XML with a sensible processing model.

XML-binary Optimized Packaging (XOP)

This is a really good new W3C Recommendation I think. Forget the SOAP stuff that creeps in. It tells you how to include binary data into MIME multi-part messages, and how to map these back to inline XML.

XOP defines an xop:Include element for references. Different to xml:include and again not part of the standard framework. Of course, in one sense it is a patheric reinvention of the wheel: SOAP disallows XML entities, but then has to rebuild almost the same mechanism. Years ago we saw much the same with HTML disallowing PIs, leading to the rise of server-side includes.

Presumably SOAP systems will build XOP into their entity handlers; which would mean that SOAP processors could not handle all XML constructs on the one hand and that XML processors could not handle SOAP+XOP constucts on the other. Isn't this the kind of incompatability split that the anti-"binary XML" people alert us to?

XLink 1.1 mooted

Some simple changes to XLink have been mooted. If they wanted to make it successful, I think the simplication the XLink should make is to remove the use of ranges from basic XLink (err, XPointer). A URI in a link should refer to a point or a well-formed entity or document: these can all be retrieved without mental gymnastics. Ranges mess things up: people wanting to implement XLink look at it and discover that it comes from the world of pointing to things that you don't want to download and manipulate as a part of the deal, and give up (rightly or wrongly).