Lists Home |
Date Index |
- From: email@example.com
- To: firstname.lastname@example.org
- Date: 15 Sep 1998 14:59:57 -0700
- Date: Tue, 15 Sep 1998 14:59:57 -0700 (PDT)
> On 14 Sep 1998 email@example.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
> > 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)>
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.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)
- OO Schemas
- From: Paul Prescod <firstname.lastname@example.org>