> Sorry, but this is simply untrue. e.g.
> <!attlist foo bar (x|y|z) x>
> states that the bar attribute on foo can take values x y or z,
> defaulting to x.
Lou, your example is *not* a list attribute! According to Goldfarb, lists
can be defined as id reference lists, name lists, name token lists, number
lists, and number token lists. You can't specify the domain of list items
in any further detail!
... various amplifications deleted ...
>> All of the above is in Goldfarb's book.
> Not in my copy it ain't!
This is futile. I would have loved to quote the page references for all
my points, but Goldfarb makes this a mammoth job due to the appaulingly
bad index. (Oh I wish I could get myself to scribble on my copy, but old
habits die hard ...)
>>SGML is a language for specifying the syntax of document structure. Its
>>ability to specify "semantics" are limited to its ability to associate
>>procedural instructions with parts of document structure (i.e. rendering
>>details). These instructions as far as I understand them are rather weak.
> We are in vehement agreement about this point. Its refusal to deal with
> semantics is exactly why SGML is such a very successful and useful tool
> -- it provides people with an interlingua for discussing the things
> which matter to them.
Unfortunately without semantics you *can't* convert meaningfully between
different syntaxes!
IMHO the merit of SGML is that it provides a common basis for defining the
syntax of different document formats. This common basis makes it much easier
to extend parsers to handle new semantics since the syntax part is already
done for you via the DTD. There is no magic - you still have to write the
code to handle the semantics yourself. This effort will be diminished by
new standards such as DSSSL and ODA which provide a common framework for
rendering documents.
Dave