HDTenEightyP/NetNews huggingface dataset:
From: pim@let.ruu.nl (Pim van der Eyk)
Newsgroups: comp.text.sgml
Subject: SGML for terminological collections
Date: 8 Apr 92 10:14:38 GMT
Organization: Faculty of Arts, State university of Utrecht

I understand there is  a project on defining DTDs for terminological collections.
Could anyone give me some information about this project (e.g. reference to 
literature) ?  How does it relate to work by the TEI ?


-- 
Pim van der Eijk                              | Trans 10, 3512 JK Utrecht, Netherlands.   
Research Institute for Language and Speech    | Email:  vandereijk@let.ruu.nl      
Foundation for Language Technology.           | Tel:    *31-30-392369      
Newsgroups: comp.text.sgml
From: robin@utafll.uta.edu (Robin Cover)
Subject: CheckMark
Organization: UT Arlington
Date: Wed, 8 Apr 1992 06:28:25 GMT


XGML CheckMark is an SGML editor distributed by Exoterica Corporation,
and it runs on Macintosh II or SE/30. It is especially designed for
retro-fitting existing documents with SGML markup.

Exoterica Corporation is at: Tel: 613-722-1700, FAX 613-722-5706.
From: pzhang@ut-emx.uucp (P. Zhang)
Newsgroups: comp.text.sgml
Subject: Info about Glyph
Keywords: machine-readable language
Date: 7 Apr 92 04:16:43 GMT
Organization: The University of Texas at Austin, Austin, Texas

Is there anyone know anything about Glyph, a machine-readable language
that transforms paper into a new data-storage medium?

I apologize if this is not the proper group for this post.
 
Newsgroups: comp.text.sgml
From: 108101@adpdp2.lanl.gov (108101)
Subject: WAIS Access to Erik's comp.text.sgml archive.
News-Software: VAX/VMS VNEWS 1.41    
Organization: Los Alamos National Laboratory, EMVAX
Distribution: comp.text.sgml
Date: Tue, 7 Apr 1992 16:53:00 GMT

What is WAIS? 

--Perry Sandoval
sandoval_perry@allin1.adpdp2.lanl.gov
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: Limerick Markup
Date: 6 Apr 92 13:53:39 GMT
Article-I.D.: ucbvax.9204061353.AA03713

Here's a shot.  The content model is:

<!ELEMENT poetry - - (line*)   -- Poetry contains lines -->
<!ATTLIST poetry  id    ID  #IMPLIED
                  class CDATA #IMPLIED  >
<!ELEMENT line  O O  #PCDATA -- One line -->

The fully-marked-up version would be:

<poetry id=lim1 class="limerick">
<line>There once was a spaceman named Wright</line>
<line>Who traveled much faster than light</line>
<line>He set off one day</line>
<line>In a relative way</line>
<line>And returned on the previous night</line>
</poetry>

However, we can map $#RS (record start) to <line> and
let the next LINE element imply the end of the previous one:

<!entity line.st STARTTAG "line" -- line start tag entity -->
<!shortref lines
          "&#RS;"   line.st -- Map record start to LINE start tag -->
<!usemap lines (poetry) -- Use LINES shortref map within POETRY elements -->
<!usemap #EMPTY (line) -- Don't use any map within LINE element -->

This allows us to mark up the exmple like so:

<poetry id=lim1 class="limerick">
There once was a spaceman named Wright
Who traveled much faster than light
He set off one day
In a relative way
And returned on the previous night
</poetry>

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
From: srn@elvin.UUCP (Steven R. Newcomb)
Newsgroups: comp.text.sgml
Subject: HyTime
Date: 14 Apr 92 15:32:11 GMT

> In a recent Communications of the ACM article about HyTime (a Hypertext/
Markus Kuhn writes:

> I read that [HyTime] will become a final ISO
> standard in April. Does anybody know more about what is going on with
> HyTime? (My favorite indicator, Erik Naggum's .signature still says DIS :-)

Well, since I helped write that article, I should probably respond to
this.  The voting closed on April 10, 1992.  However, the process is not
finished yet.  If all goes well, it looks to me as though the
International Standard version of HyTime will be published early this
summer.  But ``it ain't over till it's over,'' and nobody really knows. 

with fingers crossed,

Steven R. Newcomb, Chairman, SGML SIGhyper (International SGML Users'
  Group Special Interest Group on Hypertext and Multimedia)
c/o TechnoTeacher, Inc.                      Voice: +1 904 422 3574
1810 High Road                               Fax:   +1 904 386 2562
Tallahassee, FL 32303-4408 USA               Internet: srn@cmr.fsu.edu
From: edb@HQ.Ileaf.COM (Ed Blachman x4420)
Subject: Re: Simple Content Model Group Question
Summary: Do you really need '&'?
Keywords: Inclusive Or, Exclusive Or
Reply-To: edb@Ileaf.COM (Ed Blachman)
Organization: Interleaf, Inc.
Date: Wed, 15 Apr 92 14:42:22 GMT

In article <36931@gremlin.nrtc.northrop.com> jlankford@nrtc.northrop.com writes:
> 
> i want to express inclusive or in a content model, such as
> <!ELEMENT   AA - O ( BB | CC | ( BB & CC ))>
> 
> This is ok as long as BB and CC are not themselves complex content models.
> If they are, then entity reference could be used to keep
> the AA content model compact.
> 
> Question: is there an alternate formulation of the AA content model
> such that BB and CC appear no more than once (each)?
> essentially, i'm looking for an inclusive or idiom more elegant
> than that proposed above.

If you really need that '&'-based formulation, I'll let the group
 gurus advise you; one thing I learned from the recent discussions
 of '&' and ambiguity is that '&' is not only computationally
 expensive, it's tricky as well.

But I wonder: how important is it to you that this content model
 permit BB and CC to appear in either order?  If the order really
 doesn't matter to you, then a solution is easy:

<!ELEMENT   AA - O ( BB?, CC? )>

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


Newsgroups: comp.text.sgml
From: meggin@epas.utoronto.ca (David Megginson)
Subject: SGML and hyphenation (was re: PSGML)
Organization: University of Toronto - EPAS
Date: 16 Apr 92 07:37:16
Originator: meggin@epas.utoronto.ca
	<15APR199218251045@adpdp2.lanl.gov>

In article <15APR199218251045@adpdp2.lanl.gov> sandoval_perry@allin1.adpdp2.lanl.gov (108101) writes:

   >    15) Some documents have hyphens at the ends of lines which should be
   >        removed (and the hyphenated syllables concatenated).

   This is a formatter problem not an SGML problem. There should be no
                                                    ^^^^^^^^^^^^^^^^^^
   hyphenated words in the SGML source text. Hyphenation is a concept
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   designed specifically to fit more words on a page. It really has no
   place in the electronically stored document. That why Knuth went
   through all the trouble to come up with a good hyphenation
   algorithm so that hyphenation could be decided at print time taking
   into account the current page, line, and type-size variables.

In context, these statements are correct. However, it is important for
everyone in this group to remember that SGML is used to _describe_
existing documents as well as to _prescribe_ the format of new ones.
For example, I am writing my thesis in SGML using a slightly-modified
QWERTZ DTD, then sending it to LaTeX for printing. However, I am also
using SGML to mark up electronic versions of Old English (pre-1100)
manuscripts, where I _do_ want to mark up the original lineation
(including words broken over the end of the line), but also to be able
to combine them for text analysis. Someone working with, say, the
folio editions of Shakespeare, might also _want_ to preserve the
hyphens.  Of course, joining hyphenated words is the job of the
post-processor, not of SGML, but we should not simply dismiss problems
like hyphenation, which is significant information in some types of
historical documents.


David





--
#################################################################
David Megginson                  meggin@epas.utoronto.ca
Centre for Medieval Studies      david@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################
Newsgroups: comp.text.sgml
From: stephens@galvia.enet.dec.com (Patrick Stephens)
Subject: Re: Simple Content Model Group Question
Keywords: Inclusive Or, Exclusive Or
Reply-To: stephens@galvia.enet.dec.com (Patrick Stephens)
Organization: Digital Equipment Corporation, Galway, Ireland
Date: Thu, 16 Apr 1992 07:36:31 GMT

In article <1992Apr15.144222.2465@HQ.Ileaf.COM>, edb@Ileaf.COM (Ed Blachman)
writes:

> In article <36931@gremlin.nrtc.northrop.com> jlankford@nrtc.northrop.com 
> writes:
> > 
> > i want to express inclusive or in a content model, such as
> > <!ELEMENT   AA - O ( BB | CC | ( BB & CC ))>
> > 
> > This is ok as long as BB and CC are not themselves complex content models.
> > If they are, then entity reference could be used to keep
> > the AA content model compact.
> > 
> > Question: is there an alternate formulation of the AA content model
> > such that BB and CC appear no more than once (each)?
> > essentially, i'm looking for an inclusive or idiom more elegant
> > than that proposed above.
...
> But I wonder: how important is it to you that this content model
>  permit BB and CC to appear in either order?  If the order really
>  doesn't matter to you, then a solution is easy:
> 
> <!ELEMENT   AA - O ( BB?, CC? )>

Use <!ELEMENT   AA - O ( BB? & CC? )>

The content model
	<!ELEMENT   AA - O ( BB | CC | ( BB & CC ))>
is ambiguous anyhow - ie, when parsing, which part of the content model
does BB or CC satisfy?

Patrick Stephens
Digital Equipment Corporation

Newsgroups: comp.text.sgml
From: maguire@epas.utoronto.ca (Mark Maguire)
Subject: looking for sgml infosec references
Organization: University of Toronto - EPAS
Date: Mon, 6 Apr 1992 05:51:26 GMT
Summary: does anyone use digital signatures?
Keywords: cryptography, information integrity



Does anyone know of efforts to incorporate information security
measures into SGML applications?  I'm thinking in particular of 
the use of asymmetric cryptography to digitally sign document
elements.  Given the US DOD's use of SGML (in their CALS initiative),
I wondered whether this area might already have been addressed.
However, in looking through a couple of SGML bibliographies, I
haven't come across any references to work in this area.

Any pointers would be much appreciated.               

Cheers,

Mark Maguire

Site Coordinator
Centre for Computing in the Humanities
University of Toronto
maguire@epas.utoronto.ca Phone: (416) 978-6391

Newsgroups: comp.text.sgml
From: robin@utafll.uta.edu (Robin Cover)
Subject: Re: looking for sgml infosec references
Organization: UT Arlington
Date: Thu, 9 Apr 1992 01:41:50 GMT

Mark asks about SGML used for information security in applications:

Many introductory SGML descriptions talk about one obvious benefit of
SGML as allowing low-level data security: any textual or other data
object that has a name (GI) can have an attribute giving a security
code for that particular text element, or class of element.  We get it
for free, as one might in any database environment, or particularly,
in an object-oriented database.  Whether it's used IN applications
directly might depend upon whether a processing application uses SGML
data directly, or merely as an interchange format.  Whether SGML
mechanisms are used for "asymmetric cryptography" in digitally signing
document elements -- I'll leave for others.

Robin Cover
Newsgroups: comp.text.sgml
From: meggin@epas.utoronto.ca (David Megginson)
Subject: Re: Parting PSGML
Organization: University of Toronto - EPAS
Date: 15 Apr 92 18:16:34
Originator: meggin@epas.utoronto.ca

I did read the postings on PSGML, and I think that the problem was
just a misfocus -- the author wanted to PRE-process SGML, while the
language is really designed to be POST-processed, and the
post-processor (be it a filter to LaTeX or whatever) can decide to
throw away extra whitespace, etc.


David


--
#################################################################
David Megginson                  meggin@epas.utoronto.ca
Centre for Medieval Studies      david@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################
From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.text.sgml
Subject: Re: HyTime status?
Date: 14 Apr 92 11:37:21 GMT
Reply-To: Erik Naggum <enag@ifi.uio.no>
Organization: Naggum Software, Oslo, Norway
Originator: enag@gyda.ifi.uio.no

Markus Kuhn <mskuhn@immd4.informatik.uni-erlangen.de> writes:
|
|   In a recent Communications of the ACM article about HyTime (a
|   Hypertext/ Hypermedia extension to SGML) I read that it will
|   become a final ISO standard in April. Does anybody know more about
|   what is going on with HyTime? (My favorite indicator, Erik
|   Naggum's .signature still says DIS :-)

I'm tempted to post only the .signature...

The voting on DIS 10744 closed on April 10th, and ISO is a sturdy
organization, so I didn't expect any miracles.  But miracles do
happen.  From the Norwegian IT Standards Secretariat's director, Ernst
Kristiansen, I got the name of the right man in ISO, and Keith Brennan
of the ISO Information Technology Task Force (ITTF) was very helpful
and told me on the phone just now that there were "absolutely no
problems" with the progression from DIS to IS.

18 P members voted, all APPROVE, including Australia, Austria, Brazil,
Canada, China, Denmark, France, India, Ireland, Italy, Netherlands,
Norway, Poland, Russia, Sweden, United Kingdom, United States.  (Hmmm,
that's 17; I must have missed one in my notes from the phone call, but
it isn't Germany.)

ISO 10744 has yet to be published as such, which will require official
endorsement by a meeting of the HyTime Special Working Group in JTC
1/SC 18/WG 8, which takes place the last week of this month in Copen-
hagen, and a plenary meeting of SC 18, which takes place early next
month in Stockholm.  Keith indicated that we should expect to see the
final text in no more than two months.

I'm very pleased by this development.

Best regards,
</Erik>
--
Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
Naggum Software   |   "fuzzface"      |  ISO 10744 HyTime  |  terrigena.
Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.
From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.text.sgml
Subject: Re: Limerick Markup
Date: 9 Apr 92 13:40:55 GMT
Reply-To: Erik Naggum <enag@ifi.uio.no>
Organization: Naggum Software, Oslo, Norway
Originator: enag@gyda.ifi.uio.no

Eliot Kimber <DRMACRO@RALVM13.VNET.IBM.COM> writes:
|
|   Here's a shot.  The content model is:
|
|   <!ELEMENT poetry - - (line*)   -- Poetry contains lines -->
|   <!ATTLIST poetry  id    ID  #IMPLIED
|                     class CDATA #IMPLIED  >
|   <!ELEMENT line  O O  #PCDATA -- One line -->

(Pedantic syntax note: #PCDATA is part of the content model, which is
always enclosed in parentheses.)

Here's another shot:

<!DOCTYPE limerick [
<!ELEMENT limerick	- - (line1, line1, line2, line2, line1)>
<!ELEMENT (line1,line2)	O O (#PCDATA)>
]>

The fully-marked-up version would then be:

<limerick>
<line1>There once was a spaceman named Wright</line1>
<line1>Who traveled much faster than light</line1>
    <line2>He set off one day</line2>
    <line2>In a relative way</line2>
<line1>And returned on the previous night</line1>
</limerick>

Note that the white space before the <line2> tags is ignored.

I'd also like to use a markup which looks just like limerics are
usually formatted:

<!ENTITY line1 STARTTAG "line1">
<!ENTITY line2 STARTTAG "line2">
<!ENTITY endtag ENDTAG "limerick">
<!SHORTREF limerick
	"&#RS;"		line1
	"&#RS;B"	line2
	"&#RS;&#RE"	endtag
>
<!USEMAP limerick limerick>

<limerick>
There once was a spaceman named Wright
Who traveled much faster than light
    He set off one day
    In a relative way
And returned on the previous night


Note that the blank line is significant, in that it's interpreted as
the limerick end-tag, and thus we get rid of the problem with the
falsely recognized short reference delimiter.

|   <!usemap lines (poetry) -- Use LINES shortref map within POETRY elements -->
|   <!usemap #EMPTY (line) -- Don't use any map within LINE element -->

(Pedantic note: this would make the LINES map useless, since "line" is
never explicitly closed.)

Regards,
</Erik>

--
Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
Naggum Software   |                   |  DIS 10744 HyTime  |  terrigena.
Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.
Newsgroups: comp.text.sgml
From: rebecca@cco.caltech.edu (Mark L. Fussell)
Subject: Re: PSGML -- The qwertz dtd
Organization: California Institute of Technology, Pasadena
Date: Thu, 9 Apr 1992 06:29:51 GMT

In article <JJC.92Apr8141015@jclark.com> jjc@jclark.com (James Clark) writes:
> You've missed out a crucial part of the DTD.  Here's a simplified
> version that shows what's going on:
> 
> <!doctype titlepag [
> <!element titlepag o o (title, author)>
> <!element title - o (#pcdata, subtitle?)>
> <!element subtitle - o (#pcdata)>
> <!element author - o (#pcdata)>
> 
> <!entity space " ">
> <!shortref oneline "&#RS;" space>
> <!usemap oneline titlepag>
> ]>
> <title>title
> <subtitle>subtitle
> <author>author
> 
> ...

You are correct that I left out the oneline definition (I thought it merely a  
distraction), but for my version it reads:

<!shortref oneline
     "&#RS;&#RE;" null
     "&#RS;B&#RE;" null
      '"' qtag 
      "[" ftag
      "~" nbsp
      "_" lowbar
      "#" num
      "%" percnt
      "^" circ
      "{" lcub
      "}" rcub
      "|" verbar>

which would not affect the example (and doesn't produce extra spaces because of  
the &#RS's).  Your modification of:

>  <!element titlepag o o (titlegrp, author)>
>  <!element titlegrp o o (title, subtitle?)>
>  <!element title - o (#pcdata)>

is clearly right and solves the title's extra newline, but requires modifying a  
public DTD (and assumes knowing what the creators wanted).  Presumably this  
modification would be approved, so that part of my particular example is  
resolved.  The problem would return if: 

   *  the title was about twice as long, 
   *  you didn't want a newline in it, and 
   *  you were concerned about how it looked in the source file,
      the stated intention of PSGML

but adding the last item would be cheating since I spoke of an actual problem  
with SGML.  Of course, if you didn't care at all about appearances you could  
simply put the subtitle on the same line:
<title>The &QWERTZ; SGML Document Types<subtitle>(Version 1.1 Reference Manual)

the readability of which is dependent on the width of your "terminal".  In any  
case, having to modify an apparently reasonable DTD (especially a public one)  
to solve somewhat unpredictable "cosmetic" problems seems fairly heavy-handed.   
Personally, I think SGML and the DTDs for it shouldn't really be so concerned  
with these cosmetic issues, and wanted a way to avoid the issue altogether.

Referring back to my second posting, the problems of a space after the &nl  
(which affects whether the following newline is removed or not) and of  
undesired spaces at the end of any line (like the title line) are still left  
open.

                                      -- Mark

Mark L. Fussell
rebecca@cco.caltech.edu
From: thomas@qw3.F3SERVER (Tom Gordon, F3.KI 2665)
Newsgroups: comp.text.sgml
Subject: Defending QWERTZ, (Was PSGML)
Date: 16 Apr 92 11:57:11 GMT
Reply-To: thomas@qw3.F3SERVER
Organization: GMD, Sankt Augustin, Germany


Well, up until recently I haven't felt any need to get involved in this
discussion about PSGML.  I thought the rest of you have been doing a
fine job of pointing out the issues.  But yesterday and today, in the
process of defending SGML, some of you have made some rather nasty
comments about the QWERTZ DTD.    It would be ashame if someone out
there who might have some use for the QWERTZ DTD (and the format tool
tranlating QWERTZ documents into LaTeX and groff) would be mislead into
thinking there were problems with it.  So, I will take the
trouble to correct any misimpressions:

1)  The semantics of an SGML DTD is not specified by the SGML standard,
but by the designer of the DTD (i.e. in the case of QWERTZ, me).   The
intended meaning is well documented, if I may say so, in the users
manual.

2) Leading and trailing spaces and new lines in a QWERTZ document are
usually not significant.  The main exception is within <code> and
<verb> elements, which are intended for computer programs.  In
particular, leading and trailing spaces and newlines within <titlepag>
elements are not significant.   One needs to use a <newline> element to
force a new line.

3) The use of short references in the QWERTZ DTD serve two purposes:
a) to help minimize markup when using a normal text editor, such as
emacs; and b) to make up for shortcomings in the tool I am currently
using to translate qwertz documents into LaTeX and groff.   The short
references mapping record ends into spaces, for example, are of the
second type.

Short references were clearly not designed for this second job, as they
are wholly inadequate for this purpose.   TeX peaks through in qwertz
in some places becuase of this.  For example, there is no way to hide
the meaning of back slashes in SGML (using the reference concrete
syntax for short reference delimiters).   When a better tool becomes
available, which I hope will be soon, I will stop using short
references for this purpose.

The problems Mark Fussel has had with QWERTZ are due to the fact that
he would like to use it for a task for which it was not intended.  In
judging the quality of a DTD, please keep its intended application in
mind.  This is not to say that I am not open to modifying it to make it
suitable for other applications, so long as these changes are not
detrimental to its original purpose.

I would like to thank James Clark and Erik Naggum for their suggested
improvements to the QWERTZ DTD.  Perhaps I will make use of one or the
other idea.  Constructive criticism is always welcome.  But there is
an old saying I try not to forget:  if its not broken, don't fix it.

---
Thomas F. Gordon
GMD, FIT; Artificial Intelligence Research Division
5205 Sankt Augustin 1 / Germany
email: thomas@gmdzi.gmd.de;  phone: (+49 2241) 14-2665
Newsgroups: comp.text.sgml
From: 108101@adpdp2.lanl.gov (108101)
Subject: RTF, PSGML, and a question.
News-Software: VAX/VMS VNEWS 1.41    
Organization: Los Alamos National Laboratory, EMVAX
Date: Thu, 9 Apr 1992 18:30:00 GMT

I need to translate Microsoft RTF text files into ascii files that can be
displayed on vt100 terminals and printed on very simple dot matrix printers.
Does anyone know of a translators/reformatters? 

Someone's been writing about a "newer and better" SGML called "PSGML" or
something. May I suggest that instead of spending a lot of very valuable time
recreating & reinventing the wheel (even if it is 'simpler') that the time be
spent on improving the tools we have now, writing/improving/ DTD's, etc.

Will the public domain arcsmgl parser (on MS-DOS) produce an output file with
the entity references expanded? How a bout the UNIX version?

Perry
sandoval_perry@allin1.adpdp2.lanl.gov
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.text.sgml
Subject: Re: Parting PSGML
Date: 16 Apr 92 01:19:22 GMT
Article-I.D.: msen.1992Apr16.011922.11974
Organization: MSEN, Inc. -- Ann Arbor, MI

If you want to convert a big batch of text from something else into
SGML, you'd do well to look at tools like ICA (the "Integrated
Chameleon Architecture").  It's a parser builder, DTD maker, and
tagging system which looks powerful enough to handle most industrial
strength text munging jobs.

(available from Ohio State or from the SGML archives)

--Ed