[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: objection to docbook.dcl
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/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC