OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: DOCBOOK: 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/





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]