W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: C.9 Forbid & connector?

From: Joe English <jenglish@crl.com>
Date: Fri, 18 Oct 1996 11:46:24 -0700
Message-Id: <199610181846.AA24716@mail.crl.com>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>

David G. Durand <dgd@cs.bu.edu> wrote:

> >C.9 Should XML forbid use of the '&' connector in content models
> >(
> Well, this is a peculiar reversal for me, but since we are going to keep
> the weird semantics of SGML content models, & does not seem too burdensome.
> And it is useful in some contexts. I don't feel strongly about it, but
> we've already given up the hope that anyone can apply well known theory, or


> common knowledge in implementing the feature, [...]
> [...]
>    Maybe that's an instance of another straw for the implementor's back,
> but since we're throwing in a brick, I don't see that baking the brick with
> straw in it is going to make that much difference.

I don't recall seeing this resolution passed by the ERB,
did I miss something :-)?   What "brick" are you talking about?

Since we've dropped OMITTAG, and will probably drop inclusion
and exclusion exceptions, '&' groups are the only feature remaining
that are beyond the scope of what anyone with a copy of the Dragon Book
can handle in a day's work.

(The ambiguity restriction does not matter here: unambiguous content models
are a strict subset of regular expressions; any algorithm for matching
against general REs will also work for unambigous ones.  In fact,
the ambiguity rule can make things *easier* for implementors.)

> and & is easy when you just
> parse against the parse tree (which is what people will do).

I don't see that '&' is _easy_, but as long as we keep the
ambiguity restriction it's at least tractable.

--Joe English

Received on Friday, 18 October 1996 14:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC