Re: A modest proposal (DTD for DTDs revisited)

Many thanks to David,

I like this!

I can't say that I like the specific syntax that much,
but the general idea of being able to simply declare
element types and "attribute types" is very appealing.

David has very succesfully reduced this to the point that
a non-wizard like me can immediately see the value and merit.
Frankly, I would not go so far on terminology, but I think
that will be a matter of finding a common ground between
the vocabularies of the SGML literati and the "great unwashed"
-- to borrow an endearment from an unnamed technical committee. :-)

Here, we have a meta-language in which one can declare element 
types and their content models, modify those content models by
providing additional declarations (but without the hackery of
parameter entities), and attach attributes to element types
at will. This is fabulous!

I don't really see the value in losing the "|" connector in
expressing content models, but I guess that it does make
things a bit simpler.

The <define-model> element type is a handy shorthand that is,
I assume, a useful replacement for parameter entities --
but much clearer.

I agree that one should be able to declare that a given attribute
or attribute list applies to a named/ID'd element type, but I also
think that an element type declaration needs to be able to declare
that an attribute or attribute list applies to itself.

Finally... There have been numerous fragments of discussions
that have suggested that it might be useful to have multiple IDs
on a single SGML object -- an element, for most purposes. David
has suggested the same again. I don't understand why this would
be helpful. Is there some suggestion that an object's identity
should be, somehow, context-sensitive? That addressing an object
by one name means one thing, but that addressing it by another
name might mean another thing? And if that is the issue, isn't
it better to let the object have only one identity and to rely
on other methods to assign aliases and to express additional layers
of semantics?  Help me with this -- I just don't get it.

Regards,

Murray

  
At 12:23 AM 22-10-96 -0400, David G. Durand"  (David G. Durand wrote:
>I'd like to propose what I take to be an improved approach to the syntax of
>such things (taking into account some of the decisions already taken). I am
>also putting in the things that I think we should have, that I don't expect
>some people to like. I'm also going to just give examples, rather than a
>grammar. If the examples aren't clear enough to make sense, then that's
>useful data itself.
>
>The lack of formal semantics also reinforces the notion that this is a
>preliminary proposal, not a hard and fast prescription. I hope that it may
>be a wooden (or at least wicker)-man, but even if only a strawman, it may
>serve a purpose. The syntax is not defined because it will be whatever
>syntax we finally choose for document instances. I have used the proposed
><sdf/> empty tag syntax, as a shining example of syntactic disambiguation.
>
><document-type tag-root="document"/>
>
><define-tag name="document" contains="chapter+"/>
><define-tag name="chapter" contains="title, p+"/>
><define-tag name="p" contains="#DATA em strong li footnote"/>
>                               <!-- above == (#PCDATA | em | strong ...)* -->
>
><define-tag name="em" contains="#MODEL low-soup"/>
><define-tag name="strong" contains="#MODEL low-soup"/>
><define-model name="low-soup" contains="#DATA em strong"/>
>
><define-attribute name="xref" type="#IDREF" value-spec="required"/>
><define-attribute name="index-term" type="#DATA" value-spec="implied"/>
><define-attribute name="pickable" type="yes|no" value-spec="#DEFAULT yes"/>
>
><!-- yes, you can have a defualt value with a # in it -->
><define-attribute name="weirdo" type="#DATA" value-spec="#DEFAULT #DEFAULT"/>
>
><!-- other value-specs are possible -->
><define-attribute name="Hy-foo" type="#DATA" value-spec="#FIXED manly-form"/>
>
><!-- let's make attlists separate from elements, separate from attributes -->
><!-- A shortcut to define an attlist, and apply it to an element in one
>     declaration, possibly without even naming it, would prbably be a good
>     idea. Perhaps adding:
>         apply-to="element1 element2"
>     to define-attlist would do. -->
>
><define-attlist name="highlighted" atts="xref index-term pickable"/>
><apply-attlist name="highlighted" to="em title"/>
>
><define-attlist name="hyper-highlight" atts="weirdo Hy-foo pickable"
>                extending="highlighted"/>
><dtd-doc><p>This is the way comments should really be done.</p
>><p>We can even add a way to define a dtd fragment for the dtd-doc
>>contents. To do this we need to find a way to define the DTD for the
>>contents without preventing the DTD itself from serving as an
>>instance</p></dtd-doc>
>
><apply-attlist name="hyper-highlight" to="strong"/>
>
><!-- Note: except for relaxing the unique keyword-value restriction, all
>     of this can be compiled to SGML by a pretty simple processor. -->
>
><!-- some things we might do in whatever we choose as the doc subset -->
>
><define-tag name="codeword" occurs-in="p"/>
><!-- a mix-in tag. Valid at any point in processing of top level of a <p>.
>     Not an inclusion exception -->
><define-tag name="deemphasize" occurs-in="p em strong"/>
><!-- some tags mix more than others -->
>
><define-tag name="footnote" contains="#DATA em strong li footnote"
>            legal-anywhere-within="p" illegal-anywhere-within="footnote"/>
>                <!-- maybe something like contains="#MODEL p" would be nice
>                     for inheriting content models from existing elements -->
>                <!-- notice that we can't comment within a tag. -->
>                <!-- we keep inclusion and exclusion, but don't make them
>                     too easy to abuse -->
>
>
>Other syntactic options might also make sense:
>
>    We should probably use an ID attribute instead of the name attribute in
>the above defining forms (to aid in cross-references, and the like). The
>
>   Even with the fixed name, it doesn't look too bad:
><define-tag id="chapter" contains="title, p+">
>
>   On the other hand, since attributes, content-models, tags, and attlists
>all havewe should perhaps allow multiple ID attributes per element, and
>vary the name of the attribute for the item being defined, to make DTD
>processing and cross-referencing with XML tools easier.
>
>   I abandoned SGML technical terms for common parlance in the definition
>syntax. This could create some confusion for SGML geeks, but removes a
>significant barrier to initial understanding (and hence enthusiasm) for the
>HTML user in the street. The distinction between tag and element is useful,
>but can be pretty well approximated by "tag" and "tag and its contents." I
>think I went a bit too far in simplifying things, but if it would increase
>the user-base that would be a net gain.
>
>    This contains just about everything I would want in a DTD language, in
>a syntax that I would prefer. I didn't include entity declaration syntax,
>but you can imagine. I would (of course) include a "new-character"
>declaration that give an entity name, and descriptive text, and would map
>to an SGML SDATA entity.
>
>   Apologies for any infelicities or typos in the above, but I am in need
>of rest now.
>
>   -- David
>
>
>_________________________________________
>David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
>Boston University Computer Science        \  Sr. Analyst
>http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
>--------------------------------------------\  http://dynamicDiagrams.com/
>MAPA: mapping for the WWW                    \__________________________
>http://www.dynamicdiagrams.com/services_map_main.html
>
>
>
>

************* NOTE NEW ADDRESS AND PHONE NUMBER *****************
Murray Maloney				murray@sq.com
Technical Director              	http://www.softquad.com
SoftQuad Inc.				
P.O. Box 2025				Phone: +1 416 544-3010
20 Eglinton Avenue West, 12th Floor	Fax:   +1 416 544-0300
Toronto, Ontario, Canada  M4R 1K8

Received on Tuesday, 22 October 1996 10:40:51 UTC