HDTenEightyP/NetNews huggingface dataset:
From: obusek@oasys.dt.navy.mil (Brenda Obusek)
Newsgroups: comp.text.sgml
Subject: Re: SGML editors
Date: 21 Jul 92 15:46:13 GMT
Reply-To: obusek@oasys.dt.navy.mil (Brenda Obusek)
Organization: Carderock Division, NSWC, Bethesda, MD

lac@ecs.soton.ac.uk (Les Carr) writes:
>In <9207151228.AA09810@ucbvax.Berkeley.EDU> DRMACRO@RALVM13.VNET.IBM.COM ("Dr.
>
>Does Publisher *really* "do" SGML, or can it handle "SGML-like markup".
>--
Yest, Publisher really "does" SGML. I've had quite a bit of experience
using it, and my opinion is that it's the best product out there. Using
multiple document types is very straight-forward, the product also supports
OS/FOSI for CALS applications.



Brenda O'Busek                       |     "Today is only yesterday's
obusek@oasys.dt.navy.mil             |      tomorrow"
				     |
Advanced Information Systems         |                      U. Heep
Carderock Division, Naval Surface    |
Warfare Center                       |
Newsgroups: comp.text.sgml
From: drraymon@daisy.waterloo.edu (Darrell Raymond)
Subject: Re: SGML as Data Definition Language
Organization: University of Waterloo
Date: Tue, 21 Jul 1992 12:40:00 GMT

In article <9207201503.AA25149@ucbvax.Berkeley.EDU>, DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes:

>I do know that I have yet to be presented with a data form or 
>set of relationships that I cannot express in an SGML tag set 
>coupled with complementary processing applied to that tag set.  

  Two comments.  First of all, computationally speaking, this isn't 
saying much.  For if you allow yourself to use complementary processing, 
then it doesn't matter *how* you express the original relationships, or
which ones you do specify.  For you can smuggle all the complexity, as 
well as any extra relationships you want, into your complementary processing.
If you start out with arbitrary computing power, it's not surprising that 
you end up being able to do anything that's computable.

  However, we now have to consider problems of interchange, portability,
and separation of concerns for the complementary processing.  I assume 
(correct me if I'm wrong) that you express this complementary processing 
with a custom program that manipulates the tags to do something.  How do 
you intend to ensure that this custom program, and all the relationships 
it includes, are usable at another SGML site?  And if it is not, isn't it
fair to say that SGML hasn't really expressed this information?

>I'm not a computer scientist in the formal sense, and I'm certainly
>not a mathematician, but it is very difficult for me to believe
>that there are data types and relationships that cannot be
>expressed in an SGML tag language.  

  I think this is because you are counting on arbitrary complementary 
processing to express any relationships that can't be expressed in the
content model.  But, as I've suggested above, this is an escape hatch 
that works two ways - it allows anything to be expressed, at the cost 
that you have no way of restricting the expression to something that 
other sites can understand.

>There are certainly
>relationships that cannot be expressed in an SGML content
>model, but that is not the same thing, because content models
>are not the only way that data relationships are definable in
>SGML.  

  There is a basic lesson from database practice: express relationships
in the data model, and keep them out of the applications programs, or
else you will build something you eventually can't understand, since so
much of the semantics will be bound up in applications packages. If
SGML provides no way to communicate the structure of this complementary
processing, then parts of the data model are being buried in applications.

-Darrell.
Newsgroups: comp.text.sgml
From: Erik Naggum <erik@naggum.no>
Organization: Naggum Software, Oslo, Norway
Date: 21 Jul 1992 18:09:24 +0200
Subject: Re: Mailing list?

David Megginson <meggin@epas.utoronto.ca> writes:
|
|   In a little over a week, I will be moving to a new job where there is
|   no Usenet account available (BITNET only).  I have enjoyed reading and
|   contributing to this group, and would like to continue.  Is there a
|   mailing list which echos the traffic on comp.text.sgml?

For those without USENET access, I maintain a mailing list which
receives comp.text.sgml articles as they are archived.  To join, send
mail to <sgml@ifi.uio.no> with the subject line reading "subscribe
comp.text.sgml".  ("unsubscribe comp.text.sgml" cancels your
subscription.)

Contributions can always be sent to <comp-text-sgml@ucbvax.berkeley.edu>
for automatic posting.

There's also a BITNET list SGML-L, based at DHDURZ1, which occasionally
echoes messages from this newsgroup, and sometimes see messages that are
not posted here.  To join, send a message to LISTSERV@DHDURZ1 with the
body containing the line "SUBSCRIBE SGML-L your-full-name".

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |
                        |  ISO 10744 HyTime   |
+47-295-0313            |  ISO 10646 UCS      |      Memento, terrigena.
<erik@naggum.no>        |  ISO  9899 C        |      Memento, vita brevis.
Newsgroups: comp.text.sgml
From: cabo@cs.tu-berlin.de (Carsten Bormann)
Subject: Re: It's Not Just for Text Anymore
Organization: Technical University of Berlin, Germany
Date: Thu, 23 Jul 1992 13:48:19 GMT

Erik, please scratch that summary.

Given that your article was a rebuttal to my attempt to debunk Brian
Travis' thesis (quoting below), taking it apart in all possible ways,
I simply read it as support for that thesis.  Rereading it, I notice
that your objective may have been that of simply defending SGML
against my criticism.

>     So, the next time someone asks you what SGML is, instead 
>     of saying "it is a language used to markup text", say 
>     "SGML is a powerful tool that can be used to describe, 
>     model, and interchange data." </>

My apologies if you agree with the consensus that is building in this
group, i.e. that SGML is useful, but not particularly powerful for
this purpose.

I'm still not at ease with calling my initial article "sour grape
whining" or with accusations such as that I tried to stop HyTime in
its tracks or that I have a hidden agenda (except, maybe, that of
helping advance the state of the art).

By the way, while I sincerely like your sizeable contribution to this
newsgroup, I think that communication within a newsgroup also must
allow for informal, opinionated, quick-shot articles (I even labelled
mine as such); otherwise you miss out on the most fertile aspects of
this form of interpersonal communication.  If I need to write a
refereed journal article, I can do it elsewhere (and then and only
then, I'm going to substantiate every single item).  The quality of a
newsgroup article is not its stability against point-to-point
rebuttals, but the contribution it makes to the theme at hand.

So, please let's try to end the "battle between Erik and Carsten", as
another poster put it, and rather try to further our understanding of
the role of SGML within the future world of information architectures.

Gruesse, Carsten
Organization: University of Illinois at Chicago
Date: Wednesday, 22 Jul 1992 09:57:07 CDT
From: C. M. Sperberg-McQueen <U35395@uicvm.uic.edu>
Newsgroups: comp.text.sgml
Subject: Re: SGML and Data Representation
 <BrrMCH.4LK@watdragon.waterloo.edu>

Darrell Raymond writes:

>   I have a text of some length that contains many elements that overlap.
> I want you to find a way to tag the document so that the tags demarcate
> all the possible intersections of the elements.  For example:
>
>         <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.

Is n fixed or unbounded?  For fixed n, a simple solution is to use n
concurrent markup streams.  For unbounded n, one is limited to the
technique known as 'lying to the parser' by defining empty elements
which mark the beginning and ending of the spans you are interested in
marking:

  <!DOCTYPE demo [
     <!ELEMENT demo  - - ANY   >
     <!ELEMENT begin - O EMPTY >
     <!ATTLIST begin
               id        ID       #REQUIRED
               name      CDATA    #REQUIRED
               end       IDREF    #REQUIRED >
     <!ELEMENT end   - O EMPTY >
     <!ATTLIST end
               id        ID       #REQUIRED
               begin     IDREF    #REQUIRED >
  ]>
  <demo>
  <start id=s1 name=X end=s3>
  Now is the
  <start id=s2 name=Y end=s4>
  time
  <end id=s3 begin=s1>
  for all good citizens
  <end id=s4 begin=s2>
  to come to the aid of the party.
  </demo>

Since Elliot may (will?) claim this does the trick, and Darrell may (will?)
claim it does not, since SGML cannot enforce the matching between the
IDs and IDREFs of the START and END pairs, I think the readers of the group
need to vote on whether this fulfills the terms of the wager.  I personally
think that if Elliot can't come up with something better than this for
arbitrary n, then he owes Darrell some of that home brew.

One can also do this by pointing into the text, as allowed by HyTime
and by TEI annotation mechanisms.  They don't provide much better
validation than the example here, though.

I would be grateful, however, to know if anyone knows any existing
markup or modeling language which handles this problem more gracefully.
Darrell referred to Vincent Quint as though familiar with his work;
do Quint's languages handle this better than SGML?  How do they work?

-Michael Sperberg-McQueen
From: WOHLER@BLDVM1.VNET.IBM.COM ("Wayne Wohler")
Newsgroups: comp.text.sgml
Subject: Significant white space
Date: 25 Jul 92 03:04:56 GMT

Reference: <Brwu5J.BKp@ora.com>

If the DISPLAY element has a content model which includes #PCDATA, the
leading blanks in that data are significant and will not be treated
as separator characters.  This is because the presense of #PCDATA
causes the content of DISPLAY to be treated as "mixed content" rather
than "element content" (those are both terms used in the SGML standard).
Those leading blanks should be treated reported by the parser as data.
In the standard, refer to productions 24 and 25 (page 320 in The SGML
Handbook).

Regarding the line breaks (called "record ends" in the SGML standard),
the record end following the first line will be treated by SGML as
significant and will be reported by the parser.  The record end just
prior to the </DISPLAY> tag and just after the <DISPLAY> start tag are
not significant according to the rules of SGML (see 7.6.1, page 321 in the
SGML Handbook, for the rules to determine what record ends are significant
and which are not).  It is interesting that you did not include a
linefeed entity reference before the first line but did after the last
line.  In your application, can a line break be inferred at the start
and end of DISPLAY?  If so, I believe the rules of SGML will give you
what you want without any special coding (like entity references) or
with alternate concrete syntaxes.  In this case, the desired treatment
does not hinge on the content model of DISPLAY.

I think the bottom line for this is that as long as DISPLAY's
content model contains PCDATA and you can infer a line break at the
start and end of DISPLAY, things will work as you would like with your
original tagging example.
Newsgroups: comp.text.sgml
From: drraymon@watdragon.waterloo.edu (Darrell Raymond)
Subject: Re: It's Not Just for Text Anymore
Organization: University of Waterloo
Date: Wed, 22 Jul 1992 13:02:09 GMT

In article <ETNKNA.92Jul22122415@hisoy2.etn.ericsson.se>, etnkna@hisoy2.etn.ericsson.se (Aksnes Knut-Havard) writes:
>On Tue, 21 Jul 1992 22:09:35 GMT, drraymon@watdragon.waterloo.edu (Darrell Raymond) said:
>>   This example doesn't work for several reasons.  First, the BNF of C 
>> doesn't define C - that requires a lot of semantic information as well 
	.
	.
	.
>> Finally, are you confusing two 
>> languages? - namely, the language consisting of the set of strings that 
>> represent valid C programs (which is context free) 
>
>The set of all strings representing valid C programs can not be
>described by a context free grammar, a superset of all valid C programs
>can be recognised by a context free grammar. To recognize correct C
>programs you will need a semantical analysis as well. 

  Your correction is noted. It should be clear from the opening of my 
paragraph that I know about the need for semantic information.

  Sheesh!  You can't get away with anything in this group...but just
try to get people to use the term "data model" in a precise fashion!

  :-)

-Darrell
From: sjd@uhura.uucp (Steve DeRose)
Newsgroups: comp.text.sgml
Subject: Re: Straw man proposal for overlapping markup
Date: 28 Jul 92 13:17:26 GMT
Organization: EBT
Originator: sjd@uhura

Darrell wrote in response to my overlapping-markup proposal:

>  Can the parser validate balancing tags for overlapping elements without 
>  ceasing to be context free?  I don't think so.  (A sketch of a proof:
>  imagine a pushdown automaton stacking the opening tags, and then having 
>  to match up an end tag with some opening tag that's inside the stack).

True, this isn't context free (except that given a concrete syntax and
quantity set, there is only a finite number of possible ID values, and
so the problem is actually finite-state; but only *barely* finite).

However, ID/IDREF validation is also not context-free.  I don't see this
as a problem, but as being like type-checking in programming languages;
checking that the types of two variables in an assignment are compatible
is not context free, but is left to the semantic part rather than
the syntactic part of the language's grammer.  Readers unfamiliar with
either linguistics or compiler construction would do well to read a bit
of Chomsky to follow the current thread (not suggesting Darrell has such need!).

By the same token, it is fair to say that ID/IDREF validation is a place
where SGML defines semantics, not syntax; when various posting have claimed
SGML deals "purely" with syntax, they were incorrect.
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: Steve DeRose's Overlapping Element's Scheme
Date: 24 Jul 92 17:45:36 GMT

It would certainly work.  By extending it just a little
bit farther, you could handle discontinuous elements by
chaining elements together (let's assume we also validate
STARTREF/ENDREF pairing in the parser so we can have
a single GI name:

<discont id=start endid=next1>...
<discont id=next1 startid=start nextid=next2>
...
<discont id=next2 endid=next3 previd=next2>
...
<discont id=next3 startid=next2>

This is a lot of pointing about though.  But like you said,
there's no barrier to implementing this today with
application-defined validation.  Note too that either
the NEXTID= or the PREVID= attribute could be eliminated.
I've included both for completeness.  Allowing forward
references could be expensive for some applications.

I'm afraid I prefer modifying the content models, if
possible, since it removes the requirement to manage
a lot of IDs.  ID management is probably the single
biggest cost associated with SGML authoring, especially
in dynamic, large-document, hypertext environments like
that emerging within IBM.

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
From: drraymon@watdragon.uwaterloo.ca (Darrell Raymond)
Subject: Re: Identifying Overlaps
Organization: University of Waterloo
Date: Mon, 27 Jul 1992 00:42:18 GMT

In article <92206.101701U35395@uicvm.uic.edu>, U35395@uicvm.uic.edu (C. M. Sperberg-McQueen) writes:
>Yes, I think some people on this list would say full text indices and
>other auxiliary data structures can be classed as markup, at least under
>some definitions.  I would, at least.  External markup has some
>advantages and some disadvantages vis-a-vis inline markup, but I'd say
>it's still most usefully considered, and referred to as, markup.

  The rest of the world does not refer to B-trees and hash tables as
markup, so it can't be for the purposes of communication (with us, at
any rate) that you want to refer to it as markup.  SGML can't parse or 
validate any external structure, so it isn't as if the two types were
subsumed in the standard as markup.
 
  Calling every structuring technique known to man "markup" is about as 
sensible as calling every artifact a "document" (beware - here there 
be deconstructionists!).

-Darrell.
Newsgroups: comp.text.sgml
From: matzen@a.cs.okstate.edu (MATZEN RICHARD WAL)
Subject: Questions: SGML-B and CALS
Organization: Oklahoma State University, Computer Science, Stillwater
Distribution: na
Date: Sat, 25 Jul 92 04:54:02 GMT


SGML-B and CALS questions:

I am looking for information on SGML-B (Binary Encoding) as discussed
in the August 90 issue of the SGML User's Group Newsletter.  What is
the current status of SGML-B?  Where can I get the latest specs?

CALS:  What is the relationship between the DTD in Appendix D of
MIL-M-28001A and the DTD in Appendix B of MIL-M-3874B (or C).
What are the latest versions of these two DTD's and where can I get
online copies of the latest versions?

Any help will be appreciated.

Rick Matzen
Newsgroups: comp.text.sgml
From: drraymon@watdragon.waterloo.edu (Darrell Raymond)
Subject: Re: It's Not Just for Text Anymore
Organization: University of Waterloo
Date: Tue, 21 Jul 1992 22:58:18 GMT

In article <1992Jul20.171350.1@idicl1.idi.battelle.org>, raudabaugh@idicl1.idi.battelle.org writes:

>I view SGML as a very powerful method to describe relationships between
>entities within a document (or document type).  To suggest that SGML is
>a poor data-modeling device seems somewhat absurd.  ASN.1 encoding is also
>a poor data-modeling device so nobody uses it for that.
>
>SGML does an excellent job describing document structure.  BUT, it does not
>address context/semantic relations that data-modeling is all about.  Nor
>should it.

  I can't make head or tail of this comment.  If you "view SGML as a very
powerful method to describe relationships", then why does it not "address
context/semantic relations"?  What is the distinction that you draw between
modelling and describing?  Is it that you think that structuring means 
"identifying entities", while modelling means "describing relationships"?

>OK, why did I bring this up?  Because standards should be used for what they
>are good for.  A good data-modeling standard that sits on top of a data
>manipulation language (such as SQL) and a document description language (such
>as SGML) would be heaven sent.

  A data model doesn't sit on top of a data manipulation language, just
the reverse. The relational model came before, and is quite independent 
of, SQL.  

-Darrell.
Newsgroups: comp.text.sgml
From: meggin@epas.utoronto.ca (David Megginson)
Subject: Mailing list?
Organization: University of Toronto - EPAS
Date: 21 Jul 92 10:36:21
Originator: meggin@epas.utoronto.ca

In a little over a week, I will be moving to a new job where there is
no Usenet account available (BITNET only).  I have enjoyed reading and
contributing to this group, and would like to continue.  Is there a
mailing list which echos the traffic on comp.text.sgml?

Thanks for any help.


David
--
                 o--------------- ---------------o
                 |...            |meggin@vm.epas.|
                 |.  .avid meggin|utoronto.ca on |
                 |.  .son.centre |the internet.  |
                 |... for mediev |               |
                 |al studies.univ|               |
                 |ersity of toron|  .explicit.   |
                 |to             |               |
                 |       ..meggin|               |
                 o--------------- ---------------o
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: Data Models and SGML
Date: 22 Jul 92 15:23:23 GMT

Darrell Raymond writes:

>  I take it, then, that you would disavow the following statements
>by Travis?
>
>>   The syntactic model of SGML, however, lends itself
>>   very well to describing virtually any type of data, both
>>   in content and in relationships.
>>
>>   So, the next time someone asks you what SGML is, instead
>>   of saying "it is a language used to markup text", say
>>   "SGML is a powerful tool that can be used to describe,
>>   model, and interchange data."

I think Brian has oversimplified.  I think the better way to
say this would be to say "SGML systems can be powerful tools
for describing, modeling, and interchanging data", where by
"SGML system" I mean an SGML-based application that defines
and understands the semantics and uses as its base data storage
form SGML documents.

I think the question you are asking, at least implicitly, is
"is it useful to consider building data modeling systems
on an SGML base?"  This is certainly an interesting question,
one worth asking and investigating.  My gut reaction, as I've
already said, is "yes, it is."  You may be able to convince
me that there are relationships that cannot be represented
practically using SGML methods.

You mention that in SGML, interchange is only enabled at
the application layer.  You are more or less correct.  SGML
never promised more.  Interchange without regard to DTDs
and the semantics behind them (not defined by SGML constructs),
is only meaningful when the semantics are not important, such
as for DTD-driven SGML editors that can provide tag menus but
not formatting or other processing without additional information
(SoftQuad's Author/Editor and ArborText's The Publisher are examples).

However, there is, as I've said, no barrier to defining standard
languages for specifying semantics such that interchange between
processors is enabled.  DSSSL is an attempt to do just that, as
is HyTime, as is the Davenport project.  There is no reason you
couldn't define an SGML-based architecture for data modeling
languages and associated processors using HyTime as a model.
Note that HyTime defines validation that a conforming HyTime
engine must perform that is semantic in nature.

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