🚀 go-pugleaf

In <1802@igd.fhg.de> Hans Holger Rath writes:
>Is the first element definition equivalent to
>
>   <!ELEMENT x - - (z, ((a* | b)*)) > ???

I'm assuming you meant:
    <!ELEMENT x - - (z, ((a* | b*))) > ???

>                        _      _
>
>I don't think so and Mr. Martin Bryan in "SGML an Author's Guide", page 111 don't
>think so, too.
>
>I always thought, that the occurence indicators ("?", "+", "*") have a higher
>precedence than the group connectors ("|", ",", "&").
>
>What do the experts think about these problems?
>
>Thanks in advance,
>
 --Holger

I tried the test case with two different parsers (IBM SGML Translator
release 2 and release 3) and both flagged the B element as out of
context, which they should have.  Even if the grouping operator did
take precedence in (A* | B*), B is still invalid because the OR group
itself is not repeating and thus only A or B can be specified
(regardless of the repitition operators).  Thus, if A is specified, B
cannot be specified.  This suggests that (A* | B*) is equivalent to
((A*) | (B*)), which they are.  Both say "A repeated OR B repeated".
The grouping around the individual tokens does not change the meaning.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709

Hans Holger Rath <rath@igd.fhg.de> writes:
|
|   I've I problem with the operator precedence in SGML.

Actually, you don't.  You have a problem with some version of Mark-It
from Sema Software Technology, which in a different language could have
been explained by some arcane precedence rules at work; however, SGML
has no notion of operators or of operator precedence rules as these
terms are used in programming languages.

SGML defines a content model [126] to consist of a model group [127],
which in turn consists of a parenthesized list of content tokens with a
connector between them defining how the tokens must be satisfied within
the element content, and an occurrence indicator for the group defining
possible occurrences of a satisfied group.  A content token [128] is
either a nested model group or a primitive content token [129] which is
either #PCDATA or an element token [130].  Element tokens consist of the
name of an element, followed by its occurrence indicator.  There is no
possibility of confusion in this grammar as to which content token the
occurrence indicator applies to or how members of the list are to be
satisfied in element content.  An occurrence indicator for the element
token is no different from an occurrence indicator for the model group.

To summarize your problem: Given the two element declarations

	<!ELEMENT x (z, ( a*  |  b* ))>				(1)

	<!ELEMENT x (z, ((a*) | (b*)))>				(2)

some version of Sema Software Technology's Mark-It "SGML parser" reads
declaration (1) differently from declaration (2) such that a non-
conforming SGML document parsed with respect to the former is reported
as valid (which it is not), but when parsed with respect to the latter
it is reported as invalid (which it is).

It follows that Mark-It is not a conforming, validating SGML parser as
specified in the standard, and that any claims by the vendor that it is
must be taken with several grains of salt.

|   ... Mr. Martin Bryan in "SGML an Author's Guide", ...

Discard that book, and buy Charles F. Goldfarb: The SGML Handbook, ISBN
0-19-853737-9, instead.  Or ask questions here before you work too hard
figuring things out.  I know I would have been saved a lot of trouble if
I hadn't read SGML: An Author's Guide (Not!).

It should be fairly straight-forward to understand how Mark-It blatantly
violates the standard from reading the grammar and description of the
content model and model group, and the the clause defining conformance
to a content model ([412:14-24] in [Goldfarb]).  See 11.2.4 Content
Model (p. 409ff in [Goldfarb]), with additional material in 11.2.4.1
Connector and 11.2.4.2 Occurrence Indicator (p. 413f).

Hope this helps.

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

Erik Naggum writes:
> ... which in a different language could have
> been explained by some arcane precedence rules at work; however, SGML
> has no notion of operators or of operator precedence rules as these
> terms are used in programming languages.

I think EN strains things a bit here, with potentially misleading
results.  SGML indeed has 'no notion of [...] operator precedence' but
this does not mean Holger Rath's query was ill-formed!  The fact that
SGML expresses its operator precedence rules in its formal grammar
rather than in separate rules (as for example yacc does) does not mean
SGML has no operator precedence, only that its operator precedence
rules are implicit.

The analyses posted already seem to me to hit the case:  looks like
a bug in Mark-It.

By the bye:  EN's remarks might lead one to believe that other SGML
parsers don't have bugs; that would be a wrong conclusion.  Certainly
most of the ones I've used have a problem here or there.

-C. M. Sperberg-McQueen
 ACH / ACL / ALLC Text Encoding Initiative
 University of Illinois at Chicago

In article <93005.142005U35395@uicvm.uic.edu> U35395@uicvm.uic.edu (C. M. Sperberg-McQueen) writes:
> The analyses posted already seem to me to hit the case:  looks like
> a bug in Mark-It.

Just one further note: Holger Rath found this bug in Mark-It 2.0, which is
actually a rather old version (1988) version of Mark-It.  In the more recent
Mark-It 2.2.3 (late '91? early '92?), that bug is no longer present.

Ed Blachman		edb@hq.ileaf.com  (or)	...!uunet!leafusa!edb

I wrote:
:
|   ... which in a different language could have been explained by some
|   arcane precedence rules at work; however, SGML has no notion of
|   operators or of operator precedence rules as these terms are used in
|   programming languages.

I may have been unclear, so let me try again.

The term "operator" as used in programming languages has no counterpart in
SGML.  Programming languages specify actions, operations, to be performed
as a result of executing the code.  SGML is a descriptive language, and has
no notion of operations: Operations cannot be expressed in SGML alone.
Therefore, there are no _operators_.  The concept "operator" comes from a
different world, and is conceptually incommensurate with SGML's concepts of
"occurrence indicator" and "connector".  Thus, there is no place for the
concept "operator" in the SGML world at all.

In some programming languages, there are rules to disambiguate the semantic
order among multiple operators in a given expression, usually known as
precedence rules, modified by parentheses.  (These rules may be expressed
in the grammar, but this is indistinguishable from binding directions and
precedence rules to the language user.)  In SGML, parentheses are not used
to form expressions, but _groups_.  In any given group, only one connector
may be used (the semantics of using more than one is not defined by the
language), so there is no issue of precedence among connectors, or of
binding direction.  Moreover, by virtue of the rule that only one connector
can be used in a group, the connector effectively refers to all tokens in
the group, even though it syntactically occurs between individual tokens.
(This means that the connectors can not even be understood as "binary".)
Similarly, an occurrence indicator refers to the immediately preceding
_token_ (a group is a token in this respect), and would have been a "unary
post-fix operator" if the language had had operators.

We have therefore established that a connector refers to all tokens in a
group using it, instead of the tokens between which it occurs, and that the
occurrence indicator is unary and post-fix with respect to the token to
which it refers.  This completely removes the concept "precedence" from the
SGML world.  Similarly, we previously removed the concept "operator" from
the SGML world.

This is why I said that there could've been some notion of precedence rules
at work "in a different language".

Numerous people try to think if SGML as "code" with "operators" and all
sorts of familiar programming-language and/or regular expression concepts.
There are important similarities, which enable us to think of SGML things
in terms of familiar concepts and apply well known algorithms and
techniques to SGML grammars, such as ambiguous content models and regular
expressions, but the differences are also important, and can only be
ignored at the peril of those who do.  In fact, the differences are what
makes SGML so elusive and hard to grasp for many people who would like it
to be what they think it looks like.  That's how we can get questions which
confuse the element structure (a hierarchy, with all the attendant tree
terminology and access modes), with its linearization and fragmentation
into the entity structure, and how people can spend lots of time figuring
out that "ambiguity" in SGML isn't the "ambiguity" from language theory
(where the equivalent term is "deterministic").

SGML isn't a programming language, and never the twain shall meet.

C. M. Sperberg-McQueen <U35395@uicvm.uic.edu> writes:
:
|   ... EN's remarks might lead one to believe that other SGML parsers
|   don't have bugs; that would be a wrong conclusion.  Certainly most of
|   the ones I've used have a problem here or there.

I regret if this was a possible interpretation.  What I actually thought
and wanted to express was that with all the marketing and hype that the
Sema Group puts out about how their parser and tools support more SGML than
others, they should be even more diligent than others in making sure that
the marketing matches the product, and they have put their head on the
block voluntarily.  There is also a major difference between getting the
grammar wrong, and having a problem here and there.  This is the difference
between a bug and a design flaw.  (I'm painfully aware that products in the
computer industry _never_ match their marketing, but that doesn't mean we
should accept this state of affairs.)

Thanks to Ed Blachman for noting that a new version of Mark-It has been
published with this violation of the standard rectified.

I hope this clarifies what I had in mind.

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