From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: SGML as Data Description Language
Date: 27 Jul 92 15:46:46 GMT

Darrell Raymond writes:

>I think the last line of your solution has an error; it should be:
>
><z start refid=z1><x start refid=x1>for<x end> all<y end> good<z end>
>
>  ...at least, if I understand the solution technique properly.  A

Correct you are.

>question: could a "reasonable" application assume that the refid/id
>elements were not in fact parts of the same element, but simply two
>parts linked as in a cross reference?  In that case, a "reasonable"
>application could infer something that was not valid, and if you recall,
>I disallowed solutions that permitted invalid inferences by "reasonable"
>applications.

As SGML markup *NEVER* defines the semantics behind the markup,
there is no way to define, with SGML markup alone, that the connected
GIs are of a unit and not independent entities.  Thus invalid inferences
could be made by any "reasonable" application that doesn't understand
the semantics of the references in this case.  But since you allowed me
to include processing in my solution, I don't see how you can then
invalidate it by saying it doesn't hold if the application doesn't
understand the semantics.  Can't have it both ways.

In other words, it doesn't make sense to me to consider the case where
data may be interrogated by a system that doesn't understand the semantics
of the data structuring method.  If it is your goal to demonstrate
that SGML, without application-defined semantics, is not sufficient
to define, without ambiguity, overlapping data structures, you have succeeded,
but the issue was never in doubt.  I provided a method by which
the structures could be validated *by the parser* (via the IDrefs) even
if it still required application-defined semantics to resolve the
connections unambiguously.  I can't do better than that.

>
>>To my mind,
>>documents, and specifically text documents, are not simply
>>flat streams of characters sprinkled with identifying markup
>>here and there, but complex systems of information objects,
>
>  To my mind as well.  Why then should we be bind the future of text
>processing to a system which is based on those very assumptions?

Which assumptions are those?  If you mean "flat streams of characters
sprinkled with identifying markup", that is not at all what the
SGML standard defines.  The SGML parser sees a character stream
in, parses the markup from the data, and passes that information
to the processing application.  The parser imposes no particular
view of the data.  It is only the processing application, by
application of semantics, that defines how the data looks.  If it
chooses to see it as a character stream with embedded "controls",
it can.  If it chooses to see it as a tree structure of objects,
it can.  SGML suggests and encourages the structured, object-oriented
view of data, which is not "a flat stream of characters".
A flat stream of characters is the sort of data format most desktop
publishers use, where you have no explicit structure, merely text
mixed with format controls, which must be processed sequentially
to be properly decoded.  Part of the magic of SGML is that SGML
documents do not have to be processed sequentially to be properly
parsed (ignoring marked sections).

>
>>The question of external specifications being markup or not
>>depends in part on your view of what the document is.
>
>  This seems too evasive to me.  SGML was created to deal with markup,
>and markup is the stuff that SGML can parse and enforce.  It can't parse
>or guarantee any external structure, so far as I know (please correct me
>if I'm wrong).  The question of external specifications being markup,
>among other things, holds within it the question of whether you want to
>continue to promote SGML as a standard, I think.
>
>-Darrell.
>

Remember that the external markup may itself be defined as an SGML
document.  I think we may have uncovered a basic philosophical
difference focusing on the meaning of the term "markup".

I don't think your last sentence can hold.  SGML's usefulness as
a standard does not depend on the issue of external markup.  Also,
external markup notations and architectures have themselves been
standardized *on top of SGML*, thus making SGML's status as a standard
that much more convincing.  When you have an standard architecture
as powerful as HyTime based on SGML, it adds a lot of weight to SGML
as a potential technology solution.  To the degree that technology
choices are popularity contests, the selection of SGML for big
things (CALS, HyTime, etc.), indicates a lot of popularity, and thus
suggests that SGML has real value that warrants investigation.
This is not to say that SGML will solve all problems or that you should
choose SGML just because the U.S government or the European Community
did, but if you have to prioritize the technologies you will investigate,
which will you choose to investigate first?

If I read you correctly, you are essentially suggesting that SGML
fails as a standard because *by itself*, it won't describe a certain
class of data relationships.  This cannot hold because SGML never
intended to do that, thus it cannot fail for not doing something it
didn't intend to do.  It's existence is proof that it is sufficiently
valuable as it is.

If you want a standardized way to do what we've been calling external
markup, then design the system and propose the standard, or propose
an extension to SGML itself that will meet your needs.

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
Newsgroups: comp.text.sgml