HDTenEightyP/NetNews huggingface dataset:
From: raudabaugh@idicl1.idi.battelle.org
Newsgroups: comp.text.sgml
Subject: Re: It's Not Just for Text Anymore
Date: 23 Jul 92 03:17:32 GMT
Organization: IDI-Dublin
Nntp-Posting-User: raudabaugh

In article <BrrMAL.4HK@watdragon.waterloo.edu>, drraymon@watdragon.waterloo.edu (Darrell Raymond) writes:
> In article <23254A@erik.naggum.no>, Erik Naggum <erik@naggum.no> writes:
>> 
>>Especially harmful is ignoring things that turn out to be more essential
>>than the researcher thought.  This happens over and over, and I'm very
>>skeptical of anyone who argues that X is non-essential and therefore not
>>worth considering.  
> 
>   Thank you, Erik.  I'll repeat this to anyone that considers my problems 
> with SGML as being non-essential.  :->
> 
>>I'm willing to concede the point that the structure is the
>>essence, but SGML is in fact concerned with the linear representation,
>>and not with the structure per se.
> 
>   This is the communications-protocol view of SGML.  Would it be correct 
> to say, then, that the structure per se is captured in the DTD?  Or in
> both the DTD and some external programs?  Or just the external programs?
> Or just not at all? 

I take point with the above.  SGML is describes a document in a tree structure.
The document is then non-linear, instead it becomes 2D.  Also, a very important
feature is versioning or redlining (which I don't know the level of support SGML
has).  This makes a document more 3D.  A very important part of publishing is
to produce the most current version but also prior versions.
>     
>>I use SGML to define the syntax, and embed the semantics in
>>the application 
> 
>   Ok. This is not what a data model does, unfortunately for those who 
> thought that SGML was a data model (and perhaps that was only me).  A 
> data model defines semantics and is mostly uninterested in syntax.  The 
> relational model, for instance, defines what happens when you apply 
> operators to a relation (i.e., the semantics of the operators), but could 
> care less how you choose to represent the relation or the operators.
> 
>   What I hear Erik saying is that "the marked-up document is portable,
> but the meaning of it is anybody's guess".  This is directly due to
> the embedding of semantics in applications, and is the primary reason 
> that, without support from some data model, SGML will result in 
> non-portable, application-dependent documents.  
> 
> -Darrell.

An SGML doc is not self-describing alone to the outside world without the DTD.
And yes, SGML docs without internal DTDs fly about all of the time.  Can the DTD
describe the semantics about itself so that duplicate SGML docs don't end up
consuming space-probably.  Can it describe the semantics about relationships
between other docs that have the same DTD-maybe.  Can it describe outside
relationships to other docs-why?  This is not what SGML is for nor should it be.

George Raudabaugh
-- 
George Raudabaugh               Project Leader
Information Dimensions, Inc.    raudabaugh@idicl1.idi.battelle.org (work email)
5080 Tuttle Crossing Blvd.      
Dublin, Ohio  43017             (614) 761-7309                     (voice mail)
Newsgroups: comp.text.sgml
From: Erik Naggum <erik@naggum.no>
Organization: Naggum Software, Oslo, Norway
Date: 22 Jul 1992 19:29:26 +0200
Subject: Re: It's Not Just for Text Anymore

Carsten Bormann <cabo@cs.tu-berlin.de> writes:
|
|   In article <23246D@erik.naggum.no> Erik Naggum <erik@naggum.no> writes:
|
|   > [A number of interesting things about why, from his perspective, SGML
|   > cannot be denied to be the ultimate information modelling tool.]

Sehr geehrte Herr Dr. Carsten Bormann:

Your summary of my article is a gross misrepresentation of its actual
content.  I have no interest in discussing things with you if you are
not honest enough to not impute statements and opinions to me which I
factually do not hold, nor man enough to keep from accusing people of
religiously defending something because you have been proven wrong on
several serious counts in your diatribe against that something.

You have been most disappointing, Dr. Bormann.

To acknowledge the fact that I value your opinion when uncontaminated
by pointlessly insulting rhetorics and any hidden agenda you bring to
the discussion, I invite you to restate your arguments to this group,
concerning SGML, and not as if to me, concerning my reactions to your
sour-grapes whining about SGML's purported failings.

Sincerely yours,
Erik Naggum


--
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: wilson@MML.NCSL.NIST.GOV (Ron Wilson)
Newsgroups: comp.text.sgml
Subject: SGML Parsers
Date: 27 Jul 92 19:09:09 GMT
Organization: National Institute of Standards and Technology (NIST)

I am interested in learning more about the CONCUR and LINK features of
SGML.  Are there any available generic SGML parsers that handle these
features?

Additionally, do you know of any problems with the specification of
the CONCUR and LINK features within the SGML standard.

Any available information would be greatly appreciated.  

I have just started reading this group, so please excuse me if this subject 
has already been discussed.  You may email me directly or post to the net 
if you believe that to be appropriate.

Thank you for your time,

Ron Wilson  (wilson@mml.ncsl.nist.gov)
From: thomas@cogsci.ed.ac.uk (Thomas Plass)
Newsgroups: comp.text.sgml
Subject: EWOS
Date: 23 Jul 92 09:57:47 GMT
Reply-To: thomas@uk.ac.ed.cogsci
Distribution: comp.text.sgml
Organization: Centre for Cognitive Science, University of Edinburgh


Does anyone have the (an?) address (email/snail/fax) of the European
Workshop on SGML (EWOS) handy? 

Regards,

th.
--
Thomas Plass                                    | University of Edinburgh
Fax:   +44 31 650 4587                          | Centre for Cognitive Science
ARPA:  thomas%cogsci.ed.ac.uk@nsfnet-relay.ac.uk| 2 Buccleuch Place
JANET: thomas@uk.ac.ed.cogsci                   | Edinburgh EH8 9LW Scotland
From: plate@ruc.dk (John Plate)
Newsgroups: comp.text.sgml
Subject: Re: Markup and LPEX
Date: 19 Jul 92 20:06:59 GMT
Organization: Roskilde Universitetscenter, Danmark

In <9207171344.AA00278@ucbvax.Berkeley.EDU> DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes:

>The two are different.  LPEX (LEXX) was originally
>developed by Mike Cowlishaw, the inventor of REXX, as
>an aid for the development of the computerized Oxford
>English Dictionary.  Markup came out of Yorktown
>research.

>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

It is possible to develop parsers for markup languages like GML,
Bookmaster and SGML in Lpex. In this respect Lpex is a very flexible
tool.

-- 

:::::::::::::: John Plate, Roskilde University, Denmark :::::::::::::::
:::::::::::::::::::: Internet: <plate@dat.ruc.dk> :::::::::::::::::::::
:::::::::: Fax: (+45) 31 16 16 07 - Phone: (+45) 31 16 80 80 ::::::::::
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 00:49:32 GMT

In article <23254A@erik.naggum.no>, Erik Naggum <erik@naggum.no> writes:
> 
>Especially harmful is ignoring things that turn out to be more essential
>than the researcher thought.  This happens over and over, and I'm very
>skeptical of anyone who argues that X is non-essential and therefore not
>worth considering.  

  Thank you, Erik.  I'll repeat this to anyone that considers my problems 
with SGML as being non-essential.  :->

>I'm willing to concede the point that the structure is the
>essence, but SGML is in fact concerned with the linear representation,
>and not with the structure per se.

  This is the communications-protocol view of SGML.  Would it be correct 
to say, then, that the structure per se is captured in the DTD?  Or in
both the DTD and some external programs?  Or just the external programs?
Or just not at all? 
    
>I use SGML to define the syntax, and embed the semantics in
>the application 

  Ok. This is not what a data model does, unfortunately for those who 
thought that SGML was a data model (and perhaps that was only me).  A 
data model defines semantics and is mostly uninterested in syntax.  The 
relational model, for instance, defines what happens when you apply 
operators to a relation (i.e., the semantics of the operators), but could 
care less how you choose to represent the relation or the operators.

  What I hear Erik saying is that "the marked-up document is portable,
but the meaning of it is anybody's guess".  This is directly due to
the embedding of semantics in applications, and is the primary reason 
that, without support from some data model, SGML will result in 
non-portable, application-dependent documents.  

-Darrell.
Newsgroups: comp.text.sgml
From: terry@ora.com (Terry Allen)
Subject: Significant white space
Organization: O'Reilly & Associates, Inc.
Date: Fri, 24 Jul 1992 20:27:19 GMT

Dear News Group Readers:

I am a novice user of SGML engaged in a document translation
project for books on software.  I am using a fairly well
developed DTD that gives me an element for displayed lines
of text, in which the line breaks and indentation are supposed
to be significant, call it <DISPLAY>.

My question to you is whether it is possible to indicate
leading blank spaces (and, secondarily, line breaks)
without the use of an entity.  Given the text:

<DISPLAY>
     some blanks there
none at start of this line.
</DISPLAY>

I would like to avoid creating an unreadable set of lines such as:

<DISPLAY>
&blank;&blank;&blank;&blank;&blank;some&blank;blanks&blank;there&linefeed;
none&blank;at&blank;start&blank;of&blank;this&blank;line.&linefeed;
</DISPLAY>

(&blank; is an ISOpub entity; &linefeed; is concocted for the purpose.)
This is an approach I have seen used in two different SGML projects,
so I imagine that what I ask cannot be done, or cannot be done
conveniently.  But I should like to understand why.

If I understand correctly, the blank space is a separator in
the Reference Concrete Syntax.  Using another concrete syntax
would not appear to solve the problem throughout the
document.  But is it possible to redefine the
separator locally (in the context of DISPLAY), perhaps as the
carriage return character, and make the blank space a shortref
to the &blank; entity?  That wouldn't solve the smaller
problem of marking the line breaks, but it would avoid having
to transform the blank spaces and maintain readability in a file
that our editors may have to edit directly during production.
More interestingly, if not, why not?

I would greatly appreciate any helpful response.  Responses
claiming that the blank space is not significant in this context
or that readability should not be a concern will not be
considered helpful.

Thanks.
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: CONCUR
Date: 23 Jul 92 14:22:49 GMT

Michael Sperberg-McQueen writes:

>Eliot Kimber writes:
>
>>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.
>
>Does the standard say this?  It doesn't require a parser to parse more
>than one active doc type at a time, but does it require a parser to
>parse *no more* than one at a time?
>
>If it doesn't forbid parsing of multiple doc types simultaneously,
>then I think EK has oversimplified, and his statement should be
>recast to say "not all parsers claiming to support CONCUR will be
>able to do this in a useful way."

I think what the standard (and logic) say, is that you can only
parse against a single DTD at any given moment, although there's
no reason an interative parser couldn't interatively parse
against multiple DTDs over the same document fragment, but I don't
think that's any different, in effect.  The references I can find
in ISO 8879 for CONCUR (namely 7.1 Prolog), don't make it any
clearer for me.

My understanding of CONCUR is pretty weak, so I will defer
to Michael, who I know has studied CONCUR intensively.   My
main point was that CONCUR and the parser alone are not
sufficient to resolve or parse interactions between data
identified concurrently.  In other words, there is no
parser message that says "character string "x" is contained
by element A in DTD 1 and element B in DTD 2.  For it to
do so would go beyond the base task of parsing into
the application task of data analysis.  Of course, I could be
wrong.

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: Erik Naggum <erik@naggum.no>
Organization: Naggum Software, Oslo, Norway
Date: 23 Jul 1992 17:35:58 +0200
Subject: Re: It's Not Just for Text Anymore

Carsten Bormann <cabo@cs.tu-berlin.de> writes:
|
|   Erik, please scratch that summary.

OK.

|   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.

Yes, that was my objective.

|   >     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.

If we strike "model", I think we're much better off.

|   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).

In keeping with the tone of your article, I retract those comments.

|   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.

Yes!  This would indeed be useful, and I look forward to your
contributions.

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: mec@texhrc.uucp (Michael Chase)
Subject: Req: Library InfoMgt System Leaders
Summary: Request recommended solutions
Keywords: library,info,systems
Organization: Texaco EPTD
Date: Fri, 24 Jul 1992 22:23:16 GMT
Expires: Thu, 22 Oct 1992 22:23:17 GMT


What are the leading SGML-supported information storage/retrieval
systems currently used by DODcontractors and major universities?

Do you consider corporate central files archiving a subset of 
library information storage and retrieval?


We want to consider UNIX, MAC, and dos based systems and appreciate 
your experiences.

Are raster-to-vector converters useable? What information query
software supports SGML commented files?

Thanks,
	=Michael=
-- 
Michael Chase..................................................healing happens.
Not authorized, in any way, shape, or form, to speak for any mortal.
Email:mec@Texaco.COM || InterTexaco:mec@texhrc  Fax:713-954-6911.
 Voice:713-954-6225........SlowMail:Texaco Inc.,PO Box 770070,Houston,TX 77215 
Newsgroups: comp.text.sgml
From: drraymon@watdragon.waterloo.edu (Darrell Raymond)
Subject: Re: Data Representation in SGML
Organization: University of Waterloo
Date: Wed, 22 Jul 1992 00:58:30 GMT

 In one article, Eliot Kimber says:

>SGML was not designed to be an all-encompassing data
>modeling language all by itself.  

 In another, Erik Naggum says:

>I may think that making SGML into a
>language to describe semantics of data models is maybe not its force.

  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."

-Darrell.
Organization: University of Illinois at Chicago
Date: Wednesday, 22 Jul 1992 16:03:26 CDT
From: C. M. Sperberg-McQueen <U35395@uicvm.uic.edu>
Newsgroups: comp.text.sgml
Subject: Re: Data Models and SGML

Eliot Kimber writes:

> 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.

Does the standard say this?  It doesn't require a parser to parse more
than one active doc type at a time, but does it require a parser to
parse *no more* than one at a time?

If it doesn't forbid parsing of multiple doc types simultaneously,
then I think EK has oversimplified, and his statement should be
recast to say "not all parsers claiming to support CONCUR will be
able to do this in a useful way."

Mind you, this would be more than an academic question if there were
more than one parser which did support CONCUR.

-C. M. Sperberg-McQueen
Newsgroups: comp.text.sgml
From: drraymon@watdragon.waterloo.edu (Darrell Raymond)
Subject: Double or nothing (was: Data Models and SGML)
Organization: University of Waterloo
Date: Thu, 23 Jul 1992 02:39:01 GMT

  Never let it be said that I didn't give a man an honest chance to win 
back his beer.  Besides, I am curious to see exactly what you will settle 
for, once I make the problem a bit more ugly. So let me remove the 
requirement that your result be constrained by the content model, and just
require that the markup somehow be reasonable, where you get to define what
"reasonable" means.  You don't even have to do this in SGML. 

  Once again, consider the markup of a stream with overlapping elements
(three elements this time).

  Here is the text:

	now is the time for all good

  And the contents of each element (and of their overlaps) is defined as 
follows (where the operator "^" means intersection):

  X:	now is the for
  Y: 	is the for all
  Z: 	the for all good
  X^Y:	is for
  X^Z:	the for
  Y^Z:	for all
  X^Y^Z: for

  Note that the elements are not contiguous subsequences of text.  If 
you draw a Venn diagram with three overlapping circles and put the words 
in the various regions as the element membership requires, it might be 
easier to visualize.  Never mind that it seems bizarre.

  Now, the markup problem I pose is the following: insert tags in the 
text, corresponding to X, Y, and Z, that demarcate the various regions
in such a way that a "reasonable" person or program can identify all
the elements and overlaps, and would not infer non-existent relationships.

-Darrell.
Newsgroups: comp.text.sgml
From: sjd%ebt-inc@uunet.uu.net (Steve DeRose)
Newsgroups: comp.text.sgml
Subject: Overlapping markup
Date: 23 Jul 92 14:29:58 GMT
Organization: EBT
Originator: sjd@uhura

We're all of the same side here, right?  Those who feel troff is the
ultimate document representtion have already packed up and gone home.
It should therefore be possible to suggest that maybe SGML can't do
*everything* perfectly, without being considered the opposition.

The *possibility* of encoding anything in SGML is irrelevant.
It's very, very easy to design a language with that property.
I trust we all learned in high school that a theory that could
not be proven false/inadequate by any conceivable later data,
is therefore useless.  The question is not total power, but grace, elegance,
and usability.  In these areas SGML is optimized for some things, not all.

Now to specifics:

The overlapping markup case is perfectly well-defined, can be managed under
more sophisticated data models, and ***arises often in real documents***.
Data adapted from an actual SGML document prepared by the Brown University
Women Writer's Project:

   <speech speaker='Sir John'>
   <poetry-line>Greetings, O brave defender of our right,</poetry-line>
   <poetry-line>'Till now, I thought you knew not how to Write</poetry-line>
   <poetry-line>but heavy Morals.
                </speech>
                <speech speaker='Melissa'>
				      These my Pens imploy</poetry-line>
   <poetry-line>for all my business was to pall Your Joy:</poetry-line>
   ...
   </speech>

Read it aloud to see the scansion -- Two speakers divide a poetry line 
between them.  Both the speakers and the lines must be marked, because
both are structurally significant.  The above fragment isn't SGML.
Petri nets have some helpful properties for representing this sort of thing,
but I'm not fluent enough to say much more (see various articles by R. Furuta).

CONCUR could do this case (if there were more than one parser in the world
that supported it).  However, there are cases where CONCUR is inadequate,
such as Greek drama where occasionally the chorus and another speaker
speak in unison for a slight overlap within one or a few verse lines or
portions, or any case where instances of the same element type overlap.

Such overlaps are easy to *notate* in SGML, but none of those
ways helps; that is, they don't contribute positively to grace,
elegance, or usability, or permit validation of such structures (an
application can, but that's not SGML).

   <speech speaker='Sir John'>
   ...
   <poetry-line>Greetings, O brave defender of our right,</poetry-line>
   <poetry-line>'Till now, I thought you knew not how to Write</poetry-line>
   <poetry-line id=p1 continued.in=p2>but heavy Morals.</poetry-line>
   </speech>
   <speech speaker='Melissa'>
   <poetry-line id=p2 continued.from=p1>These my Pens imploy</poetry-line>
   <poetry-line>for all my business was to pall Your Joy:</poetry-line>
   ...
   </speech>

Unless Elliot has a much better solution, I think he owes Darrell the beer.

Steve DeRose
From: drraymon@daisy.waterloo.edu (Darrell Raymond)
Subject: Re: Markup
Organization: University of Waterloo
Date: Tue, 21 Jul 1992 12:41:05 GMT

  When I gave the example:

>now is the time <use-troff-not-SGML> for all good men
 
  Eliot said:

>The element <use-troff-not-SGML> is not a valid SGML tag

  Which may be true, but is irrelevant.  I was presenting an example
to illustrate a general definition of markup, not one limited to 
descriptive markup or SGML markup.

>That Darrell used this example suggests that he has made the
>common confusion of SGML with procedural formatting languages
>like TROFF and DCF/Script.

  I don't suffer from this confusion.   However, even if I did, it's 
not important, since the example was intended to illustrate a definition 
of markup that includes both descriptive and procedural forms. 

-Darrell.