This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: subsetting: excluding CALS table
Hi Norm
There were two arguments that seemed to sway the TC:
1. That allowing both models would open the possibility (in a
DTD-based DocBook validator) of totally incoherent tables,
for example a table with a CALS thead and an HTML tbody.
Dear TC:
1. There are many other structural aspects where DTD is insufficiently
constraining, in which cases the spec becomes even more important [1].
2. Since the XHTML table elements would be in the XHTML namespace, and
the DTD would list them with a prefix, user could very easily see if
they are mixing table elements from the two models/namespaces.
2. One of the use cases for adding HTML tables was cut and paste.
Bob collected evidence that suggests most HTML tables have other
markup in them (A's, SPAN's etc.) that wouldn't be valid anyway so
cut and paste wouldn't often work.
... but also *would* work in many cases :)
Also, since someone (perhaps you) mentioned in some earlier thread,
people could use WYSIWYG editors such as Amaya to create XHTML tables,
then paste 'em into their DocBook documents. I suspect many use general
XML editors (without support for CALS), which is tedious when authoring
tables. Even when many free/cheap editors will support CALS, there still
will be lots of advantages due to familiarity, ease of use, ease of
processing (some people need to write their own transformers to get some
special/custom/proprietary format).
I'm not personally worried about the cut and paste issues. Users can
fix the other markup if they do cut and paste.
I agree. If there are many docs, do it via XSLT.
Mostly what HTML tables
buys is the "familiarity" of the model
I agree.
and some common presentational
idioms.
I care more for the semantic/structural/non-presentational aspects :)
The former point concerns me even less since RELAX NG has no trouble
with parallel models :-)
Exactly. Normative DTD plus normative spec to separate the two table
models, and optionally/additionaly, automatic validation of this
constraint via RNG.
As Bob points out, we didn't really close the issue.
I see a light behind the horizon ... perhaps the sun will shine again :)
Paul was unable
to attend the January telcon where we initially made the decisions.
And he missed the February telcon too, so I guess this will come up
again this month.
I'm really heartened by your post. I think noone represents the spirit
of DocBook as you do, so I believe that the way we suggest is the right
one, since you approve it.
Tobi
[1] ... as with ulink:
tdg-en-html-2.0.7/tdg/en/html/ulink.html
"Linking elements must not be nested within other linking elements
(including themselves). Because DocBook is harmonizing towards XML, this
restriction cannot easily be enforced by the DTD. The processing of
nested linking elements is undefined."
--
http://www.pinkjuice.com/