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.
You can also constrain an attribute value to be a name token, a name, an
idref or a list of any of those things.
That's about it for constraints though. Several people would probably
agree that SGML is relatively under-endowed with features
(feature-challenged?) for constraining attribute values -- some have
even gone so far as to say that you shouldn't use attributes at all,
since formally there's no obvious way of distinguishing
<thing foo=bar> .... </thing>
<thing><foo>bar</foo> .... </thing>
> Similarly you can't
> constrain combinations of values of different attributes for each tag.
This is true, in the sense that you cannot say "if the bar value is x
then the ping value must be q". There is a (rather annoying) constraint
which says that the values specified as legal for *all* attributes of a
given element must be disjoint, i.e. you can't have two attributes on
the same element which both take values 'yes' or 'no'.
>You also can't specify how deeply a given element can be nested. There is no
>notion of context to hang a constraint on.
Huh? What's a dtd do then? If I say
<!element div0 - o (div1+)>
<!element div1 - o (div2+)>
<!element div2 - o (div3+)>
That seems to specify pretty exactly to me at what depth of nesting each
element can occur, and also provides some pretty detailed notions of
context.
If you mean that, given the definition
<!element div - o (#pcdata|div) >
there's no way of preventing infinite recursion, then no there isn't.
And a good thing too. If you mean that there's no way of telling for a
given <div> occurrence how far down the tree you are, then no there
isn't, but you wouldn't expect to find such a thing in a grammar anyway
would you? You can (of course) define an attribute 'level' to do it for
you, if you anticipate a processor incapable of working it out.
>All of the above is in Goldfarb's book.
Not in my copy it ain't!
>> SGML is not about interchange of formats, but about interchange of
>> document structure.
>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.
>I look forward to studying DSSSL.
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.
>Cool it! We are trying to understand what it means to exchange document
>structures expressed in one format to another. This is an important issue
>and it isn't helpful to flame.
Thank you, and apologies for being obnoxious.
Lou