SGML: comp.text.sgml (CTS) Digest, Sample Issue
From comp-text-sgml-request@naggum.no Sat Mar 18 11:09:24 1995
Return-Path: <comp-text-sgml-request@naggum.no>
Received: from naggum.no by utafll.uta.edu (4.1/25-eef)
id AA01034; Sat, 18 Mar 95 11:09:07 CST
Received: from archive.naggum.no by naggum.no with SMTP
id <AA17602> for <robin@utafll.uta.edu>; Sat, 18 Mar 1995 15:05:29 UT
Date: 18 Mar 1995 15:05:26 UT
From: "comp.text.sgml digest" <comp-text-sgml-request@naggum.no>
Reply-To: comp-text-sgml@naggum.no
To: comp-text-sgml@naggum.no
Message-Id: <CTSD-08-26@naggum.no>
Precedence: list
Subject: comp.text.sgml digest Vol 8 #26
Status: R
comp.text.sgml digest 1995-03-18 Volume 8 : Issue 26
The comp.text.sgml digest is volumed monthly with 10 articles per issue.
Articles from the newsgroup are collected from the University of Oslo,
Norway and NETCOM, San Jose, California.
Continued maintenance of the comp.text.sgml archive is made possible in
part by grants from: The SGML Users' Group, the SGML Users' Group Special
Interest Group for Hypertext and Multimedia (SIGhyper), SGML Open; and in
part by subscription fees from the mailing list. For subscription info,
see the end of the digest.
(Ref) Art # Author Subject
----- ----- ----------------- -------------------------------------------
8210 Andreas Björklind SGML Contacts in Vietnam
8211 Andre J. Emmell Equations in SGML
8209 8212 Chuck Till Re: EBT DynaBase: are you a customer?
8211 8213 Robert Lockwood Re: Equations in SGML
8195 8214 Erik Naggum Re: PCDATA vs RCDATA
8109 8215 Erik Naggum Re: Proposed PDF FIPS report
8191 8216 Joe English Re: Help for HyTime
8187 8217 Howard Kaikow Re: Editing Massive Files
8143 8218 Jacques Deseyne Re: Intellitag
8190 8219 Paul Grosso Re: PCDATA vs RCDATA
----- ----- ----------------- -------------------------------------------
Administrative:
Send subscription requests and delivery problem reports to
<comp-text-sgml-request@naggum.no>. Send articles (only) to
<comp-text-sgml@naggum.no>. The posting service is free.
----------------------------------------------------------------------
Article: 8210 of comp.text.sgml
Newsgroups: comp.text.sgml
From: abj@ida.liu.se (Andreas Björklind)
Subject: SGML Contacts in Vietnam
Message-ID: <abj-1703951324560001@hampus.ida.liu.se>
Sender: news@ida.liu.se
Organization: LIBLAB, IDA, Linköping University, Sweden
Date: Fri, 17 Mar 1995 12:24:56 GMT
I'm looking for SGML contacts in Vietnam with at least basic
SGML knowledge.
The reason? I may be going there (Hanoi) to teach basic SGML and I
would like to know who may be able to continue the long term SGML
teaching and consulting effort. "Legal documents" is the operative
term in the project, by the way.
Yours sincerely,
Andreas Björklind
--
----------------------------------------------------------------------------
Mr. Andreas Bjorklind, Laboratory for Library and Information
Science (LIBLAB), Dept. of Comp. & Info. Sci., Linkoping University,
S-581 83 Linkoping, Sweden. Tel. +46 13 28 19 69, Fax +46 13 14 22 31
Internet: abj@ida.liu.se, AOL: Bjorklind
----------------------------------------------------------------------------
------------------------------
Article: 8211 of comp.text.sgml
From: "Andre J. Emmell" <sgml@globalx.net>
Newsgroups: comp.text.sgml
Subject: Equations in SGML
Date: 16 Mar 1995 20:39:45 GMT
Organization: Global-X-Change
Message-ID: <3ka7mh$ois@news.globalx.com>
Does anyone know an elegant solution on handling of equations
in SGML. I am addressing a serious scientific organization
who wants to convert to SGML and to streamline their documentation
which contains a lot of equation.
Any good editors you have found? You may contact me directly if
you would like.
Thanks in advance
Andre J.Emmell sgml@globalx.net
------------------------------
Article: 8212 of comp.text.sgml
From: charles.till@nt.com (Chuck Till)
Newsgroups: comp.text.sgml
Subject: Re: EBT DynaBase: are you a customer?
Date: Fri, 17 Mar 1995 08:46:11 -0500
Organization: Northern Telecom
Message-ID: <charles.till-1703950846110001@131.253.106.155>
References: (8209) <3ka2vu$ftn$1@mhade.production.compuserve.com>
In article <3ka2vu$ftn$1@mhade.production.compuserve.com>, Alan Burns
<74364.2774@CompuServe.COM> wrote:
> Is anyone else out there working with EBT, or simply awaiting the
> release of DynaBase? Their release schedule has changed, and I would
> be interested in hearing from other organizations which are hoping
> to use this product upon its release.
>
> We hope to use DynaBase as part of a fully SGML compliant repository
> for text and other media objects, for republishing purposes. All of
> our objects are meant to have equal status, such that many new
> publications will be created with combinations of various objects.
> We do not want to pre-judge what those combinations may be.
>
> DynaBase looks promising, but we wonder about other solutions.
We are just beginning to evaluate DynaBase.
--
Chuck Till, Sr Mgr - Cust Info Systems Integration, Northern Telecom
RTP NC USA +1 919 992 3225 charles.till@nt.com
------------------------------
Article: 8213 of comp.text.sgml
From: rlockwood@novell.com (Robert Lockwood)
Newsgroups: comp.text.sgml
Subject: Re: Equations in SGML
Date: 17 Mar 1995 15:23:13 GMT
Organization: Novell
Message-ID: <3kc9h1$p1g@grok2.orem.novell.com>
References: (8211) <3ka7mh$ois@news.globalx.com>
X-Newsreader: WinVN 0.92.6+
In article <3ka7mh$ois@news.globalx.com>, "Andre J. Emmell" <sgml@globalx.net> says:
>
>Does anyone know an elegant solution on handling of equations
>in SGML.
ADEPT*Editor by ArborText (sales@arbortext.com) supports equations
in SGML based on the AAP standard DTD. They have a nice equation
editor within their product that facilitates creation and
maintenance, and their publishing engine supports postscript output.
I do not know whether other products would support this markup
directly on the publishing end, however.
Robert P. Lockwood rlockwood@novell.com
------------------------------
Article: 8214 of comp.text.sgml
From: Erik Naggum <erik@naggum.no>
Newsgroups: comp.text.sgml
Subject: Re: PCDATA vs RCDATA
Date: 18 Mar 1995 03:51:08 UT
Organization: Naggum Software; +47 2295 0313
Message-ID: <3004487468.339283@naggum.no>
References: (8195) <3k8jnm$5i1@news1.shell>
[kendall thomason shaw]
| Can someone help me understand the difference between these two statements:
|
| <!ELEMENT lmnop - - (#PCDATA)>
|
| <!ELEMENT lmnop - - RCDATA>
Joe English has answered well, but a few minor points still need emphasis.
seen from a validation viewpoint, PCDATA (Parsed Character DATA) means that
non-markup characters (a.k.a. data characters) are valid in the content,
i.e., this is where SGML ceases to be concerned with the validity of the
structure of the document.
seen from an application viewpoint, PCDATA is the meat on the markup bones.
if SGML is getting a space shuttle safely into orbit and back, PCDATA is
the payload, the ultimate reason we're doing the exercise, but which is
nothing without the space shuttle (structure) to support it.
now, there are still a few hairy points to consider. PCDATA is the kind of
payload where you are allowed to hook straps around it and weld it to the
shuttle and whatnot to keep it there -- i.e., markup within it will be
recognized by the SGML parser as "its business". this applies to end-tags,
entity references, processing instructions, comments, the works. RCDATA
(and CDATA) is the kind of payload that you aren't allowed to touch, and
you store it in a special container that protects it from shocks and such.
only the RCDATA (and CDATA) containers are broken. Joe shows the proper
way to package frail goods in space: marked sections. you never take those
RCDATA/CDATA containers with you on real flights. they are there because
sometimes you have to do dangerous things, such as releasing that cord that
is, technically speaking, keeping you from discovering DS9 on your own.
even if RCDATA and CDATA were fixed, you would not want to use them,
because they look just like other boxes, and if they really are special,
you should always using special marking tape. it's not sufficient to trust
the guys who stuff things into the payload bay to know that containers from
Frobozz, Inc, are fragile. you mark it with "FRAGILE" all over the place.
SGML users and parsers can use the same redundancy to keep from clobbering
important data.
also inclusions, which is like packing a sledgehammer with your test tubes,
but you don't want to use inclusions. people who use inclusions are likely
to pack their dry clothes where a broken thermos will do maximum damage.
in space, and in SGML, that's the difference between getting a regular
"welcome home" or your very own entry in the history books.
after having thought long and hard about advantages and disadvantages, I
think it is preferable to have elements whose content is (#PCDATA) and
_nothing_ else. HyTime talks about pseudo-elements that, among a few other
things, are unnamed elements that contain only one piece of data. instead
of an element containing data and sub-elements, it contains pseudo-elements
among the sub-elements. thus, the "mixed content" metaphor breaks down,
and there will be counter-intuitive results, to compound the counter-
intuitive ways that #PCDATA interferes with parsing, especially in the
treatment of whitespace. the ability to use #PCDATA in a content model is
only a (very) convenient short-hand, and it is sometimes necessary, but
should be viewed as a temporary hack. (it is so convenient that you will
be taught several ways to abuse it in almost any book on SGML, but most of
these books only tell you what's possible, not what's good practice,
because the SGML community didn't have the experience to know the
difference. this is changing.)
#<Erik>
--
the greatest obstacle to communication
is the illusion that it has already taken place
------------------------------
Article: 8215 of comp.text.sgml
From: Erik Naggum <erik@naggum.no>
Newsgroups: comp.text.sgml
Subject: Re: Proposed PDF FIPS report
Date: 18 Mar 1995 04:17:23 UT
Organization: Naggum Software; +47 2295 0313
Message-ID: <3004489043.055254@naggum.no>
References: (7916) <entrpoop.793664966@access3>
(8048) <3jf9fe$j4d@dove.nist.gov>
(8051) <9503062038.AA15222@source.asset.com>
(8068) <3ji141$bc1@bmerhc5e.bnr.ca>
(8109) <D5AusI.8rI@actrix.gen.nz>
[M. James Bartley]
| A PDF file is either a 7-bit ASCII file or a binary file. If it is a
| 7-bit ASCII file only the printable subset of the 7-bit ASCI code plus
| space, tab and newline (return or linefeed) is used. If it is a binary
| file, the entire 8-bit range of characters may be used.
[Gary Houston]
| Er, 7-bit ASCII file _OR_ a binary file??? Doesn't the "bit" in 7-bit
| imply binary? This sort of confusion seems to be getting far too
| common, now that it's even turning up in "reference manuals".
is this really a problem? in very advanced set-theoretical terms, "ASCII"
is a subset of "binary" files. it is a very important subset with a number
of special properties not shared by other binary files. another subset is
"7-bit text", of which "ASCII" is a subset. yet another subset is "8-bit
text", of which "7-bit text" is a subset. you may note that "GIF file" is
also a subset of "binary file", and that all files are a subset of the
"finite bit string". I'm not sure it would be useful or interesting to
call every data object, including programs, data files, operating systems,
computer graphics, WWW, astronomical observations from the space shuttle,
etc, "finite bit strings", even if they are. I think you're the one to
introduce confusion, Gary.
| And that non-ASCII option, does the statement "entire 8-bit range of
| characters may be used" imply that only character sets that fit in 8
| bits are supported?
no. these aren't even theoretically interesting questions.
part of the fun with human languages is that we can establish precise
terminology for reference purposes, and then use a much more sloppy
language to get ideas across. my current .signature is relevant.
#<Erik>
--
the greatest obstacle to communication
is the illusion that it has already taken place
------------------------------
Article: 8216 of comp.text.sgml
From: jenglish@crl.com (Joe English)
Newsgroups: comp.text.sgml
Subject: Re: Help for HyTime
Date: 17 Mar 1995 11:18:01 -0800
Organization: Call Really Late Dialup Internet Access
Message-ID: <3kcn99$nco@crl2.crl.com>
References: (8079) <3jmr4s$ki0@babbage.imag.fr>
(8191) <3kango$jdl@pubxfer2.news.psi.net>
W. Eliot Kimber <kimber@passage.com> wrote:
>For URL addressing there are essentially two solutions:
>
>1. Use a URL as the system identifier of the document entity you want to
> link to. I favor this approach.
>
>2. Define a notation-specific location address (notloc-form) and use it to
> contain the URL. Steve DeRose and David Durrand prefer this solution in
> their HyTime book (my HyTime book perfers the other, as you might expect)
Which of these two solutions is most appropriate depends
on whether one sees the Web as an SGML application that
uses Internet protocols or as an Internet application that
uses SGML as a document format.
I think that, overwhelmingly, the Web is an Internet
application first and an SGML application second.
URLs are not *just* system identifiers for HTML browsers,
though they can be used that way; they are a fundamental
part of Internet applications, SGML-aware or not.
It's not unreasonable to reify them as attributes
or as a HyTime notloc form in HTML, since HTML is
a DTD specifically designed for Internet hypertext.
Panorama (I assume) will be an SGML application first
and an Internet application second. The first solution--
using URLs as system identifiers-- has clear advantages
in this case. But for the current generation of Web browsers,
which are not, and show no signs of wanting to be, general-
purpose SGML viewers, first-class URLs in HTML are appropriate.
Of course, the two solutions are not mutually exclusive.
Web browsers can *and should* resolve URLs in system identifiers;
(they *should* understand entity declarations to begin with;
unfortunately most don't). But URL-valued attributes (<A HREF>,
<FIG SRC>, &c;) shouldn't be removed from HTML or even
deprecated, I feel.
--Joe English
jenglish@crl.com
------------------------------
Article: 8217 of comp.text.sgml
Newsgroups: comp.text.sgml
From: kaikow@standards.com
Subject: Re: Editing Massive Files
Originator: kaikow@mv.mv.com
Message-ID: <D5Mp7z.4E1@mv.mv.com>
Sender: kaikow@standards.com
Reply-To: kaikow@standards.com
Organization: MV Communications, Inc.
Date: Sat, 18 Mar 1995 09:04:46 GMT
References: (8119) <3k1njq$rvh@dove.nist.gov>
(8187) <3k7mdu$6e5@vaneyck.ahip.getty.edu>
Is VEDIT freeware/shareware/commercial?
Where does it live on internet?
In article <3k7mdu$6e5@vaneyck.ahip.getty.edu>,
Joe Shubitowski <joe@ahip.getty.edu> wrote:
>In article <3k1njq$rvh@dove.nist.gov>, bagwill@sst.ncsl.nist.gov (Bob Bagwill) writes:
>>P.W.A. Kools (pkools@inter.nl.net) wrote:
>>: Does anybody out there know of an editor under DOS/Windows which will handle
>>: large (20Mb plus) SGML files. Word doesn't, although it does allow you to read
>>: the file. Any replies much appreciated.....
>>
>>If you like (or don't mind :-) vi, DOS elvis stores text in a temporary file,
>>instead of memory.
>>
>>--
>>Bob Bagwill <rbagwill@nist.gov>
>
>I use VEDIT under DOS. I have used it on text files as large as 400MB...
>
>Joe Shubitowski
>
>
>
>
>
------------------------------
Article: 8218 of comp.text.sgml
From: jdeseyn@pophost.eunet.be
Newsgroups: comp.text.sgml
Subject: Re: Intellitag
Date: Fri, 17 Mar 95 15:38:50 CDT
Organization: EUnet Belgium, Leuven, Belgium
Message-ID: <3kc4q9$9sq@news.Belgium.EU.net>
References: (8143) <3k3gsl$efa@news.Belgium.EU.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage
In article <MARTIN.95Mar9090730@hchworth>, <martin@hchworth> writes:
>
> Last year there was a brief discussion of the limitations of
> WordPerfect's Intellitag. At the time I didn't keep a copy of the
> conclusions, but now find I need to know them.
>
> Can somebody please post any experiences of Intellitag, reasons to
> buy, not buy etc? Alternatively mail them to me and I'll post a
> summary.
>
If you go to the home page of WordPerfect at the WWW, at
http://www.wordperfect.com
the first button can take you to three articles, including one white
paper on WordPerfect SGML Edition, which is going to be the new version
of IntelliTag.
We are working with a (pre-?) beta release now and it looks quite well.
Unfortunately, there is not a single byte of documentation at the moment,
so we are quite ignorant about the possibilities of templates and styles.
Our appreciation of IntelliTag 1.2 will come Real Soon Now !
------------------------------------------------------------------------
Jacques Deseyne
Witbakkerstraat 34
B-9051 Sint-Denijs-Westrem, Belgium
E-mail : jdeseyn@pophost.eunet.be
"Nani, sed in humeris gigantium" ;-)
------------------------------------------------------------------------
------------------------------
Article: 8219 of comp.text.sgml
Newsgroups: comp.text.sgml
Approved: erik@naggum.no
Date: Sat, 18 Mar 95 11:43:16 GMT
From: Paul Grosso <paul@arbortext.com>
Message-ID: <9503181143.AA23706@texcel.no.texcel.no>
References: (8190) <3kaft0$3ii@crl2.crl.com>
Subject: Re: PCDATA vs RCDATA
[Joe English]
| Don't ever use the second form (RCDATA); it's evil.
While Joe's cautions on RCDATA are worth taking careful note of, I wouldn't
go so far as to say the concept is evil (I reserve that comment for CDATA
elements).
For DTDs that wish to have a "verbatim" sort of element in which things
such as SGML examples can be placed, I recommend an RCDATA element. The
key thing to remember is that ETAGO strings (e.g., the "</" string) must be
"escaped" by writing the "<" as a character entity reference. In fact, I
generally recommend the use of the character entity < in place of "<"
whenever you want a "<" character in your text. SGML-aware editors will
generally handle this automatically.
RCDATA marked sections are also an option, but are much less likely to be
supported, especially in terms of composed output. 8879-wise, I'll agree
they are techically a good way to get your data parsed correctly, but
practically, I think the careful use of an RCDATA element (as described in
the previous paragraph) is the better way to go.
I will agree with Joe that CDATA elements are very dangerous because aside
from having all the pitfalls Joe mentions about RCDATA, there is no way to
"escape" problematic characters. That is, even a helpful SGML-aware editor
can't do anything to help when the user enters the "</" string: escaping it
by using an entity reference is not an option. The best that can be done
is to give an error message to inform the user that the next time the
document is parsed, their CDATA element will surprisingly end sooner than
they think and subsequent parsing errors will be almost guaranteed.
paul
--
Paul Grosso
VP Research, ArborText, Inc.
and
Chief Technical Officer, SGML Open
Email: paul@arbortext.com
------------------------------
SUBSCRIPTION INFORMATION
Individual subscription is NOK 70.00 (~= USD 11.10) per volume.
Commercial subscription is NOK 175.00 (~= USD 27.75) per volume.
University subscribers are eligible for discounts.
Individual subscriptions must be paid by an individual, and is intended
for one person, only. Commercial subscriptions are intended to be shared
among more than one individual. Aliases and sub-mailing lists must have
commercial subscriptions.
Semi-annual subscriptions cover six volumes at the price of 5. Annual
subscriptions cover twelve volumes at the price of 10. Annual and
semi-annual commercial subscriptions may be invoiced upon request.
INTERNATIONAL PAYMENT
Checks may be drawn on U.S. banks in U.S. funds, but please, no checks
above NOK 100. VISA and MasterCard charges accepted. SWIFT transfer are
accepted for charges above NOK 500. Please write for details.
Please note that the currency of payment is Norwegian crowns (NOK). The
NOK is worth approximately USD 0.16.
End of comp.text.sgml digest Vol 8 #26
**************************************