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

Re: C.9 Forbid & connector?



At 9:51 AM 10/19/96, Joe English wrote:

>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
>	b) [...]"
>
>    [ 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.
I don't think we should emulate the policy of having errors that may break
some parsers and documents, but are not reportable.

>Also note that checking for ambiguity is straightforward --
>as long as there are no '&' groups.

I agree. But it's not something you can look up in a book.

>That only works if the content model is unambiguous:
>consider  '( (a,(b|c)) & (a,(b|d)) )' after seeing 'ab...'

This seems to me to support removing the unambiguity distinction.

>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 [1]) 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.)
>
>[1] 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
>the standard.

More reason to drop unambiguity, as that feature died an unlamented death
practically at the inception of the project.

You have convinced me though, that both features should be dropped, & and
unambiguity. We should take advantage of the slack allowed in the standard,
and hope that SGML parser writers who care about XML will adapt.

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
http://www.dynamicdiagrams.com/services_map_main.html



Follow-Ups: