http://norman.walsh.name/2010/05/12/calsns 13 18 2010-05-12T08:41:30-04:00 Norman Walsh 2010 Norman Walsh CALS table markup is shared across many XML schemas. Does it make sense to create a namespace for this common vocabulary? In the past few months, I've been approached independently (I believe) by two different groups exploring the possibility of creating a namespace for CALS table markup. Namespace deniers and folks who believe that only one, centrally-managed vocabulary are required for the entire corpus of human discourse will recoil in horror (or ridicule), I'm sure. I think it's an interesting idea. It would not be technically difficult to describe the vocabulary in a modern schema language. The historical difficulty with a common schema for CALS table markup is that the leaves (the contents of the cells themselves) need to be able to contain the “host vocabulary” markup. For example, a DocBook chapter (db:chapter) might contain a CALS table that ultimately contains a CALS table cell (cals:entry), but that cell must be able to contain a DocBook link (db:link). What would be gained from a CALS table namespace? XML editors would be able to recognize tables in any vocabulary and switch to an appropriate table editor widget. XML viewers would be able to recognize tables in any vocabulary and display them as such. A web browser, assuming (perhaps foolishly) that future web browsers do something rational with namespaces, could have a built-in set of CSS rules for CALS table elements, for example. Reusable modules (for example, XSLT stylesheets) could be written for CALS tables and simply imported by vocabularies that support them. Putting CALS tables in a separate namespace would remove the semantic collision that occurs when CALS tables and other table models (for example, HTML) are both added to the same vocabulary. Authors, when encountering table-like elements in a vocabulary with which they are not familiar would be able to know for sure that the semantics of the markup really are the CALS semantics. That's a pretty nice list. What would we lose? Well, first of all, there's a lot of legacy. That would either require a large backwards incompatible change in a short, sharp shock, or a long grace period when both the old and new markup are supported. There are plenty of folks out there who will argue that the right number of namespaces in a document is zero, that for authoring purposes, namespaces are too much trouble. If you can't have zero namespaces, having exactly one is the next best thing. In any event, more than one is too many. I don't subscribe to this point of view (Quelle surprise!). Almost all of my documents contain at least three namespaces (DocBook, XLink, and XInclude). But I am not unsympathetic to the view that authors have trouble with namespaces. On the other hand, if we think MathML and SVG are going to be widely used, then authors will get used to islands of “other namespace” markup in their documents; perhaps because authoring tools completely hide the fact, which they could also do with CALS table markup. To the extent that authors rely on non-namespace-aware tools to process their documents (yes, Viginia, it still happens), putting table markup in a namespace may be problematic. Where does that leave us? If no table markup existed and we were inventing it from scratch, I'd be firmly in the “put it in a namespace” camp. As it is, I think it would be a hard sell in the community. I've been burned once, I'd be reluctant to take up such an effort without some indication that the community really wanted to go there.