> > What does it mean to "subclass" the PAREN element type when it is clearly
> > used in two different contexts with two different content models? The
> > answer: there is no PAREN type, really. There is a PAREN "tag" that can
> > be used in completely different ways in completely different contexts.
> >
>
> Why would anyone put a paren around args? Args is already a grouping
> construct - paren is redundant there. In the second case, wouldn't you
> rather use <EXPRESSION> than <PAREN>? It always seemed to me that the
> elements of the DTD should sit at least one level above lexing, but PAREN
> is something the lexer does away with. And doesn't it seem that ARGS and
> EXPRESSION are subclasses of a parent grouping element?
I used PARENs to use an example of the same token being used for
different things that people would be familiar with.
Ar ARGS and EXPRESSION logically subclasses of a parent grouping element?
Sure, at some level. But they don't share a content model, and they don't
necessarily share attributes, so at the tree validation level, they are
not really related.
Tables and figures are also related as "block-level objects" (in many
DTDs), but also do not share a content model or attributes. This is why I
feel strongly that element type subclassing is quite different from
inheritance in documents, just as in OO.
> Are you calling for the resurrection of SHORTREFS? Content models should
> ideally address the abstract syntax tree. Lexical constraints address
> content. If you want to cross them, you need something like SHORTREFS (or
> BNF.
Sorry, I was speaking loosely. I'm more interested in constraints at the
tree level than lexical constraints. But I don't see why you think that
lexical constraints need something like SHORTREFS or BNF. What about
regular expressions? What would be fundamentally wrong with something
like this:
<!ELEMENT FOO (LHS,"=",RHS)>
Paul Prescod