Re: C.9 Forbid & connector?
David G. Durand <firstname.lastname@example.org> wrote:
> At 11:46 10/18/96, Joe English wrote:
> >(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.)
> Yeah, once the check is over. It's doing the check that is unpleasant and
You don't have to perform the check though, even in
a validating parser:
"4.329 validating SGML parser: A conforming SGML parser
that can find and report a reportable markup error if
(and only if) one exists.
4.267 reportable markup error: A failure of a document
to conform to this International Standard [...] other
than a semantic error [...] or:
a) an ambiguous content model
[ 9.3, "Conforming Systems", p. 215]
In other words, 8879 (for better or worse) places the
burden of ensuring non-ambiguity on the DTD designer,
not the parser.
Also note that checking for ambiguity is straightforward --
as long as there are no '&' groups.
> >> 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.
> You just keep a flag as to whether the & group is used up yet or not.
> Gross, but servicable and easy....
That only works if the content model is unambiguous:
consider '( (a,(b|c)) & (a,(b|d)) )' after seeing 'ab...'
> That means the whole ball of wax, to me. If I had to implement SGML's
> ambiguity I'd implement and ambiguity check and match against the parse
> tree for the model. If I'm parsing that way, what's a single bit of
> additional state per moel token? As I say, I'm not emotional about kereping
> &, just don't see why not.
Since '&' groups are the only feature that makes the ambiguity
restriction difficult to test for, and it's also the only feature
(other than OMITTAG ) that makes the restriction desirable from
the implementor's point of view, the logical conclusion would
be to drop '&' groups. (Not that I am advocating that position --
I think XML should keep both '&' groups and the ambiguity restriction,
but should not require validating parsers to check the latter.)
 Final note: OMITTAG, in particular start-tag omission,
*cannot work* unless content models are unambiguous and deterministic.
This is because of the way "contextually require element" is defined in