« Jini up in non-geological time | Main | There was only one catch and that was Catch-22 »

XInclude: it depends

Norm Walsh points to a hole in how the XInclude and xml:base specs interact:

"I think what pains me most about this situation is that XInclude was in development for just over five years. It went through eleven drafts including three Candidate Recommendations. [...] If we can't get a 16 page spec right in three CRs, what hope do we have of getting the XSL/XML Query family of specifications right?"

Yow. Between this and xml:id|c14n, I wonder if there isn't a process issue with the core XML work. That's twice a group of baseline specs haven't been specced to work properly together. And twice backward compatibility is being preferred over getting things straight. Over time that is going to have to paid back in some form of technical debt.

It's not so much the size of the specs that matter as the surface area of the interactions between specs. I see Norm has the Dijkstra testing quote at the top of his entry, but I'm not sure Dijkstra had this class of coordination problems in mind.

One thing that's been bothering me for a while: it does not seem that XML integrates well with other XML in the general case. That is when you move past XML1.0 and into the XML 'family' of specs, things seem to unravel ever so slightly. I worry that the XML family has essential composition problems unless you stick to a flat, dictionary-like structures a la Atom or RSS.


April 1, 2005 11:02 PM

Comments

Mike Champion
(April 2, 2005 08:07 PM #)

I think it's deeper than a process issue. Or maybe it's a management of expectations about process. Think of the "turn and attack" post : design by committee efforts that attempt to think through all those interdependencies are more or less doomed, at least in the first few (million?) iterations. Maybe the most realistic approach is: Start with the simplest spec that could possibly be useful and let Orgel's Second Law ("evolution is smarter than you are") do the dirty work. The real problem with that in the XML context is that the W3C seems unwilling to let Father Darwin's verdict stand about specs that have lost the struggle for existence, e.g. XLink, XML 1.1, etc.


Of course, as Norm mentions, XQuery decided long ago to do the exact opposite. That will be an interesting experiment.

Elliotte Rusty Harold
(April 3, 2005 03:19 PM #)

There may be a process issue with the W3C (there are probably several) but this case doesn't prove it. Norm is wrong about this. xml:base's interaction with validation was not an oversight. The working group knew about and discussed this issue, and decided on the behavior you now see in the recommendation. Personally, I think they made the right choice.

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1519