- From: Deborah A. Lapeyre <dlapeyre@mulberrytech.com>
- Date: Thu, 29 May 1997 09:01:47 -0700 (PDT)
- To: w3c-sgml-wg@w3.org
1) This is to second the plea that we look very very carefully at requirements on this one. Could someone state what we all feel they are? please? 2) Can we also look at this as a cost (and to whom) and benefit (and to whom). Parameter entities in DTDs: - are the mechanism DOCBOOK, TEI, and others have used for extensibility and customizing - are a godsend in DTD maintenance and legibility - make multi-DTD libraries practical Cost = to parser, browser developers (small number, but critical constituency) This is a development loss. Gain = to DTD writers, maintainers, (larger number, at least this has been true for SGML) Cost to Users/Authors = not much. this is a setup problem and setup is not done all that often Gain to User/Authors = again definite, but hard to see. The fine art of customization becomes less an obstacle This is a production system gain. 3) Soapbox: We can finesse this: Yes, it will be necessary (as of this writing) to preprocess an SGML DTD to make an XML DTD anyway, and the PEs could be resolved at that point. But why throw out the good bits? Wasn't the XML subset supposed to include the most useful parts of SGML while omitting the marginal, the broken, the overly complex, and the arcane? PEs in DTDS are one of the few universally useful concepts. Why should it be harder to write and maintain a good XML DTD than it is to do the same in SGML? End soapbox. Sorry :-) --dal ======================================================================= Deborah A. Lapeyre Phone: 301-231-6933 Mulberry Technologies, Inc. Fax: 301-231-6935 6010 Executive Blvd. Suite 608 E-mail: dlapeyre@mulberrytech.com Rockville, MD USA 20852 =======================================================================
Received on Thursday, 29 May 1997 12:01:50 UTC