🚀 go-pugleaf

Darrell Raymond writes:

>    <X>now is the <Y>time</X> for all good men</Y>
>
>  This tagging shows an X and a Y element that overlap only for "time",
>but have their own content otherwise (X is "now is the time", and Y
>is "time for all good men").  If it helps, think of yourself describing
>a Venn diagram and all its possible intersections.
>
>  What I want you to do is tell me how you would mark up such a document
>where the number of overlapping components is n.  Note that the number of
>possible intersections is 2**n - 1.  And to count as "expressed by SGML",
>the description must be within what SGML can enforce; if the DTD permits
>some other reasonable interpretation of the document, you lose.

This relationship cannot be expressed solely in terms of SGML
content models because SGML only expresses complete containment.
The solution of defining empty elements that mark the boundaries
of the shared part doesn't really cut it because it can't be
validated by the parser, and thus fails Darrell's requirement.
But Darrell knew this when he asked the question.
I think that use of the CONCUR feature is also not adequate because
the document can only be parsed against one active DTD at a time,
and thus the application must manage (and validate) the sharing
of data across elements in the concurrent DTDs.  The structures
as coded must still be independently valid in each DTD.
In other words, say I have this use of CONCUR:

     <(A)X>now is the <(B)Y>time</(A)X> for all good men</(B)Y>

If I understand CONCUR correctly, then element X is only recognized
when DTD A is in effect, and element Y is only recognized when
DTD B is in effect.  It is up to the processing application to
recognize the overlap between these two elements by comparing the
results of the parsing against DTD A with the results of
parsing against DTD B.

I think I could cry foul in that Darrell and I were using different
base requirements for the solution.  I was including application
processing driven from SGML-tagged data, while Darrell has disallowed
it.  If I had understood that I never would have made the bet,
because I know as well as Darrell that I would lose.
Darrell rightly pointed out that including application processing
enables anything computable (thus my confidence), while I didn't
appreciate Darrell's desire to do it all with parser-provided
mechanisms.  So it goes.

Darrell's point is made:  there are data relationships that cannot
be expressed soley in SGML content models.  But we knew that already.
I realize now that this all stemmed from Darrell's literal interpretation
of Brian Travis' oversimple statement.

Darrell, if you want to collect the brew, let me know--we should have
some nice wheat beer ready for drinking by the end of August.

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