Re: A modest proposal (DTD for DTDs revisited)

At 10:40 AM 10/22/96, Murray Maloney wrote:
>Many thanks to David,
>
>I like this!

Thanks.

>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.

I didn't intend to lose it. (A problem with definition by example), but to
show that if #PCDATA is only allowed in models like (#PCDATA | x | y | z)*,
we might just a specail syntax for that case, nipping in the bud the
obvious, but illegal, (#PCDATA, foo, #PCDATA, bar, bletch). By having
"#PCDATA-containing" models have a special format, we elimiate a source of
possible confusion.

models like "(a|b)+, c" should still be allowed. We should remove SGML's
funky paren rules as well, and go for a standard operator-precedence
syntax. Pulling together adjacent like operators is easy to do for a
computer, and a potential source of error for a user.

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

I actually think we should keep parameter entities, but have built in
notation to eliminate some of their idiomatic uses -- cases where by
definition we are synthesizing useful abstractions that SGML lacks.

>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.

yes. Incomplete again.

>
>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.

Well, I didn't get it either. But I was thinking that in this case we have
namespaces for elements, attributes, content models, and attribute lists,
and unique IDs (_within_ each namespace). If we wanted to use the ID/IDREF
mechanism to implement these references, however, we would have to add an
extra parameter for the Unique_id, because there is only _one_ global
namespace for ID and IDREF.

   So I can see the use for several namespaces, each with a parser-enforced
uniqeness and reference semantics. This is not a must-have for me, but I
now see why people would want it.

   -- David


RE delenda est.
I am not a number. I am an undefined character.
_________________________________________
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

Received on Tuesday, 22 October 1996 12:54:56 UTC