[Prev][Next][Index][Thread]

Re: C.9 Forbid & connector?




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

> >C.9 Should XML forbid use of the '&' connector in content models
> >(11.2.4.1)?
>
> 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

  jenglish@crl.com


References: