🚀 go-pugleaf

MATZEN RICHARD WAL <matzen@a.cs.okstate.edu> writes:
|
|   I concur that the above definitions imply that inclusions cannot affect
|   definition 11.2.4.3 directly.  That is, inclusions cannot satisfy
|   primitive content tokens.

... because inclusions _aren't_ primitive content tokens, but a set of
allowed elements which apply if the primitive content tokens would
otherwise not include them.  This is splitting hairs, though.

|   However, I believe that 11.2.5.1 confuses the issue (lines 14-21)
|   and this should be cleared up in the definitions.

A minor point on vocabulary.  "Definition" applies to individual terms,
as defined in clause 4, while "11.2.4.3" is a "clause" (or sub-sub-sub-
clause) and contains "requirements", not definitions.  I'm thus not sure
whether the last word should be "definitions" or "requirements".  (Also,
I assume that "lines 14-21" refer to Goldfarb [418:14-21], but regard
this only as a request for unambiguous references.)

Assuming that you mean "requirements", I'm inclined to agree with you.
11.2.5.1 can be hard to grasp, because of the approach to describe by
example, rather than in principles or abstract rules.  Now, the idea is
clear: An inclusion means that any number of elements with generic
identifiers from the set of applicable inclusions is always valid
before, between, and after any (complete) elements specified by the
content model.  Within the content of each such element, the same rule
applies to its content model, recursively.

|   Regarding exclusions and their affect on ambiguous content models:
|
|   What about <!ELEMENT B (X | A | X) >.  This is an ambiguous content
|   model.  But if "X" is excluded from B is it still ambiguous?  By
|   11.2.4.3, to be ambiguous there must be an element that occurs in an
|   instance of B, that can satisfy more than one primitive content
|   token (X, in this example).

Remember that "the priority rules stated earlier in 11.2.4 are not
considered in determinging whether a content model is unambiguous"
[415:3].  It's precisely these rules that specify what it takes to
conform to the content model.  The exclusions are only used to forbid
elements, rather than actually modify the content model to remove them.
Likewise, inclusions only allow elements with generic identifiers from
the set of applicable inclusions, before, between, and after the model
group tokens in the content model.

|   But, by definition 4.131 (above), X is not allowed anywhere in the
|   content of B.   Doesn't this mean that X cannot occur in an
|   instance of B, and thus, the content model is not ambiguous when X is
|   excluded?

Yes, if the exclusions are known at the time the content model is
checked for ambiguity.  No, if the exclusion of X is inherited from a
superior element as it occurs in the document instance.  I would favor
an interpretation which didn't differentiate between inherited
exclusions and those that are declared with the content model, and thus
it would be reasonable to consider (un)ambiguity without consideration
of exceptions at all.

|   Even if I am missing something, and the example above is not a valid
|   argument that exclusions can affect the ambiguity of content models,
|   I believe that the definition of "ambiguous content models" is still
|   misleading because:
|
|   1. inclusions are a component of content models, and...

Yes, as they apply to the content model of the element in which they are
declared.  No, because they apply to content models of elements which
are allowed in that element's content.  The latter makes it very hard to
analyze a content model for (un)ambiguity without full knowledge of the
rest of the declarations with which it occurs.  This is an intractable
position.

|   2. a kind of ambiguity can be introduced by inclusions: between
|   inclusions and primitive content tokens.  Resolving ambiguity by
|   disambiguating rules while parsing the document instance, is not the
|   same as not being ambiguous.

The "order of priority" in [412:14-24] is clearly intended to make
inclusions a third-rank citizen, and it applies only if an element can't
satisfy a content token in the content model.  I don't see this as an
ambiguity, really.

If you're missing something, I think it's only that exceptions are
inherited by sub-elements, and that it is, in general, impossible to
know what exceptions are in effect until the element occurs in the
document instance, thus thwarting a priori analyses.

|   If the definition of ambiguous content models applies only to model
|   groups then why not restate it as such?  Thus, removing any possible
|   confusion to implementors and users about what it covers (and what
|   it does not).

Hmmm.  I think the text already does, with the back-reference to 11.2.4
in 11.2.4.3, although at the first n readings, I thought it only applied
to repetitions of a given token.  (Which would render a content model
like (A+, A) unambiguous, but impossible.)  It could be made even more
explicit, by stating that

	Regardless of exceptions, a "content model" [126] cannot be
	ambiguous...

|   I appreciated Eric's response and learned from it.  More comments
|   from any and all will be appreciated.  Anne Brueggemann-Klein has
|   sent me a copy of her paper on "Unambiguity of SGML Content Models".
|   I am also working on a paper on ambiguity.  I would like to hear
|   more on this issue.  Is there a concensus in the SGML community
|   regarding the equivalence of ambiguous content models and ambiguous
|   model groups?  Does anyone feel that the definition is misleading or
|   causes other problems?

I think Brueggemann-Klein's work did away with the problems, and I
strongly support her assumption that ambiguity is a characteristic of
the content model model group, only.  Further, I see no need to consider
exceptions, primarily because they complicate the matter so much, even
when you do know them all, which you generally don't.

This discussion has clarified the handling of exceptions for me, and I
can make my code much more elegant.  (Plus, I discovered a bug in my
parser which complained if an element was allowed by a superior content
model, but excluded from the current element's content.)

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.