- From: Murray Maloney <murray@sq.com>
- Date: Tue, 24 Sep 1996 11:29:13 -0400
- To: Charles@sgmlsource.com
- Cc: "W. Eliot Kimber" <kimber@passage.com>, W3C SGML Working Group <w3c-sgml-wg@w3.org>
At 02:08 PM 24-09-96 GMT, Charles F. Goldfarb wrote: >Michael Sperberg-McQueen wrote: > >>(Using the same syntax for declarations and instances cuts the size of >>the grammar approximately in half. It also reflects a firm belief that >>structured information belongs in SGML documents.) > >I believe in the second sentence, but the first one sounds like a red herring to >me, because: > >1. The implementation code isn't cut in half, or anything like it. You still >have to process the semantics of the declarations. Ya, but Michael was not commenting on the implementations, only the grammar. > >2. The grammar may be reduced, but now you have to define and document a DTD. Yes, exactly. That is what I would like to be able to do. SoftQuad developed an internal tool -- DTDocumenter -- to read a DTD and transform into a SGML instance with its own DTD just so that we could document a DTD. If the DTD were in standard SGML instance syntax, then we could use Panorama to display the DTD with whatever stylesheet we wanted to document it. A DTD for DTDs could also include a formal way to include a human readable description of the element and attribute declarations. That would be a good thing! > >3. Most users, and many experts, have trouble distinguishing tags, from >elements, from element types. If we use elements to define elements, the >confusion will only get worse. The fact that so many users have trouble distinguishing these things should be telling us that these distinctions are not very important to them. Honestly, I don't see why they should be important to users. Users want something that they can understand and SGML is not something that can be easily understood. Before I get flamed for saying that, please allow me to elaborate on my position. I am not an expert on SGML by any stretch of the imagination. A brief conversation with any of the real experts in the crowd who know me will confirm that. I have been lurking on this list until now because I did not want to slow you all down with ill-informed questions. But... I want to use something that I can understand. To some extent, SGML is that. That is, to the extent that I need to understand it, SGML is understandable. My failure to understand starts when I can't do something that I think should be obvious or when I get a result that I don't expect. (RS/RE rules are a perfect example of that.) Now, back to DTDs. I want someting that I can work with in one tool. I want to be able to read and write a DTD. I want to be able to declare an element type and its attributes, and I want to be able to explain the whys and wherefores right there in the DTD in such a way that a downstream processor can produce reasonable documentation. I also want to be able to _add_ attributes to an element type. (That is, I want to be able to have multiple attribute declarations that affect the same element type. And no , I don't think that parameter entities are good enough.) Thanks for taking the time to consider what I have to say. Please carry on. This is the most valuable series of discussions that I have ever encountered in this community. > Murray Maloney murray@sq.com Technical Director http://www.softquad.com SoftQuad Inc. P.O. Box 2025 Phone: +1 416 544-9000 x2219 20 Eglinton Avenue West, 12th Floor Fax: +1 416 544-0300 Toronto, Ontario, Canada M4R 1K8
Received on Tuesday, 24 September 1996 11:33:09 UTC