Re: DOCBOOK: objection to docbook.dcl

[Adam Di Carlo <adam at onshore dot com>]

Tony, thanks for your kind words, historical information, and
clarification.

Let me restate my position, based on your discussion and Karl's.


* Question of Purpose

Is the declaration a baseline interchange model which expresses the
lowest common denominator supported by well-known or widely used SGML
parsers?

Or is the declaration, on the other hand, a normative description of
what it is to be a DocBook SGML document?

It cannot be both.  Clarification of its status is requested from the
OASIS committee.

This is very important for me, as the Debian packager, because how I
package this will affect thousands and thousands of users, and I want
to conform to the standards and get it right.


The rest of my commentary reflects on the use of 'docbook.dcl' as a
normative SGML declaration for DocBook SGML documents, and problems
with it as such.


* NAMELEN

Since SUSE (and only SUSE, I think) ships this with this declaration
on, a review of problems experience by the SUSE community is rather
illuminating.  For instance, the phpdoc software has a configure.in
which actually checks for NAMELEN setting of 44 and emits a warning
stating the user must raise this to 54
<URL:http://cvs.php.net/viewcvs.cgi/phpdoc/configure.in?rev=1.61&content-type=text/vnd.viewcvs-markup&sortby=author>

I suggest this value be raised to at least 54, perhaps more
generously, but I don't really know what foul consequences may be
raised by that.


* SUBDOC NO

Honestly, I can understand SUBDOC being turned off.


* OMITTAG NO

Tony said:
> The conventional wisdom is or was that different SGML parsers were
> likely to infer different combinations of tags is you left off too
> many.  In fact, in the bad old days, I had one project where I had to
> use a specific parser (not sgmls or nsgmls) because that parser would
> infer the tags that I wanted and sgmls/nsgmls would just complain.

Given a presumption that DocBook 4.1 or greater are using more modern
SGML parsers, is this restriction still valid?


* Document Character set is too restrictive

I can understand the document character set being set the way it is
and especially a hesitancy to change it.  (I think I have make the
Cyrillic problems worse with my divergence from the SDATA stuff).

OTOH, if this declaration is normative, I would think it should allow
internationalized use.  Anything else seems quite Anglocentric.



-- 
.....Adam Di Carlo....adam@onshore.com.....<URL:http://www.onshored.com/>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: docbook-request@lists.oasis-open.org