> 
> On 14 Sep 1998 matt@veosystems.com wrote:
> 
> > > 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.
> 

Don't you mean "In my mind's eye they don't share a content model"?
You are making statements about the characteristics of systems you
haven't seen yet (OO Schemas or whatever) and certainly haven't used.
Once you _can_ declare them subclasses of a parent grouping element,
you might find you start doing things differently.  You might not, but
you can't really make such statements until we've got some proposals
on the table.

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

I know your opinion here.  But inheritance is just a subset of
subclass relationships (subclass is an as-a relationship, inheritance
is an is-a relationship, and all is-a relationship are also as-a
relationships).  We have yet to see how this plays out in XML, and
even though you AF gurus may have a head start, I don't think even you
have enough info to make categorical statements.  But it'll be an
interesting conversation.

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

Datatag?

What's wrong is it doesn't identify the "=" as an operator, so either
you know it's an = sign by default, in which case it's redundant,
or you have an expression but no way to know what the operator is.
You are mixing levels - you've got parsing and lexing mixed, which is
what made SGML so twisted.

Matthew
matt@veosystems.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)