The biggest advantage I see is that this gives an opportunity to standardize which subset of the original CALS table spec is supported. There doesn't seem to be an agreement there yet. The only standard subset is the Exchange subset, but I often see other subsets.

Am I the only one who'd never heard of CALS tables before this?

(But I did my googling...)

Re namespaces - I'm in the "I want to believe" camp.

How would this design compare to using/improving the existing XHTML markup for tables? Are these tables in the sense of presentation, or tables in a more SQL-ish sense, or most likely I suppose, a little of both.

If they're at the data end, there's a growing pile of tech (D2RQ etc) for mapping tabular SQL data into RDF. Having a nice clean namespace for this stuff would probably help apply similar tricks to markup...

The "nested grammars" section of the RELAX NG tutorial (13 in the XML-syntax tutorial, 14 in the compact-syntax tutorial) explains how to do "doughnut" schemas that are independent of what can go in the doughnut hole. Here's the example schema:

cell.content = notAllowed
start =
  element table {
    element tr {
      element td { cell.content }+
    }+
  }

And here's the sample that includes it, overriding cell.content:

start =
  element doc {
    (element p { inline }
     | grammar {
         include "table.rnc" {
           cell.content = parent inline
         }
       })*
  }
inline =
  (text
   | element em { inline })*

when reading your "What would be gained" list I couldn't help but think "That's what they said about xlink" so was somewhat amused to see at the end of the article that you admitted to having been "burned" before.

'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'

They might, or they might vote with their feet and use html5 (or html5-style markup) where namespaces, well formedness and lots of other good things are brushed under the carpet.

AT NAG the internal markup to an in-house DTD uses CALS tables and MathML extensively but we don't use any namespaces internally. When generating pdf (with 3b2 - now arbortext print publisher) we process the cals directly, and for (x)html the stylesheets add xhtml or mathml namespaces as required while generating the public files.

I think the case is stronger for tables than links, but yeah, once bitten, twice shy. Perhaps all is already lost.

I have always been a fan of namespaces. When I was working on the Elsevier DTD we included SOExt table into in its own namespace. We even put entry back into our namespace because it had its own content model, differing from the SOExt entry content model (as you indicate above). Because we used a DTD, we used some namespace binding trickery to get the CALS elements in the 'cals' namespace and get entry into our namespace, all without a prefix. I admit that few people understood this. (I am no longer working with Elsevier.)

How would this affect RFE 2964576 ("disallow table in entry")? I regret being the user who "pointed out that the table entry element permits table in the entry element." (Regret, because I might have found that capability useful.)

Mike,

I don't think it's related. The CALS semantics forbid tables inside tables, all this essay considers is whether or not the CALS elements should be in a namespace.

As for the nesting issues, I think entrytbl or HTML tables are your only options. My guess is that nested tables are forbidden because circa-1980 formatters couldn't cope. Today they can, but short of revising CALS, I don't think we can do anything about it.

(That said, you are of course free to extend DocBook and allow it if your processing system can cope.)