HDTenEightyP/NetNews huggingface dataset:
From: fred@osf.org (Fred Dalrymple)
Subject: Re: man page standards
Organization: Open Software Foundation
Date: Wed, 2 Sep 1992 18:07:30 GMT

In article <23570@alice.att.com> jaap@alice.UUCP () writes:
>In article <23320D@erik.naggum.no> enag@ifi.uio.no (Erik Naggum) writes:
> > jaap <jaap@alice.att.com> writes:
> > |
> > |   [ Deleted ]
> > 
> > Sigh.  OSF is committed to use the work of the Davenport Group, and the
> > Davenport Group uses the CFCM work.  You can get more information about
> > the Davenport Group from Dale Dougherty <dale@ora.com>.  The Davenport
> > Group working documents can be FTP'ed from ftp.ora.com in the directory
> > /pub/davenport and subdirectories.  The material is also mirrored at
> > ftp.ifi.uio.no in /pub/SGML/DAVENPORT.

This needs a little clarification.

Davenport is not the uniform single body that this seems to imply.
There is a working group under the Davenport banner that is associated
with the CFCM.  There is a different working group also under the
Davenport banner that is using HyTime architectural forms to produce a
specification for documentation indexes, glossaries, and other
link-oriented-kind-of-stuff.  These are two different working groups
that are independent of each other.

OSF has not made an official statement of "commitment" to any
Davenport work as yet (or CFCM work either).  We are participating in
the HyTime working group, and would like to use the specifications,
but first those specifications need to get finished...  We are not an
active part of the CFCM activities right now (though we're trying to
stay in touch).  So, to be clear:  OSF has not made any commitment to
"use the CFCM work" via or independent of Davenport.  This isn't to
say that we won't -- just that we haven't made any commitment yet.


>So what?  Half of the world is committing itself to Davenport.  It
>doesn't prevent doing other things as well, at least, it apparently
>didn't stop OSF to specify the reference Semantic Markup Language
>(RSML) for technical documentation according to the report released in
>June 1992.

OSF created the RSML language before Davenport existed, so it isn't
surprising that Davenport "didn't stop OSF [from specifying] RSML."

We made RSML publicly available in June 1992 because of discussions
with CFCM.  They were pursuing a path which seemed to be consistent
with some of what we had done with RSML, so, CFCM and OSF felt that
it could only help the process to make RSML available for CFCM to
build upon, if that's what CFCM wants to do.

Please note that we didn't do RSML as a long-term "standard" solution
to manpage markup.  We see RSML as a short-term "stepping stone"
between our previous use of the regular manpage macros, and our future
use of the SGML solution that we're in the midst of finishing.

Fred Dalrymple

fred@osf.org
OSF
(617) 621-8855
From: pstseng@hplpst.rigel (Ping-Sheng Tseng)
Newsgroups: comp.text
Subject: Scribe on PC?
Date: 23 Aug 92 17:13:31 GMT
Reply-To: tseng@hpl.hp.com
Distribution: comp
Organization: /users/pstseng/.organization


	Where can I get (buy or ftp) the Scribe typesetting program 
	for PC?

	Ping
From: ag129@cl.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.text.sgml
Subject: Re: External Entities and Public Identifiers
Date: 28 Aug 92 19:44:48 GMT
Reply-To: ag129@cl.cam.ac.uk (Alasdair Grant)
Organization: U of Cambridge Comp Lab, UK


Surely the answer is not "a ubiquitous SGML entity manager" (Eliot 
Kimber) since that would be proprietary to SGML. I would rather see
a _general_ entity manager, and have PUBLIC references map on to
that in some standardized way.  I'm not suggesting that the scope of
SGML PUBLIC entities be made more general, just that that set should
be a subset of a much larger set of entities.  To me, the obvious
candidates for this would be X.500 or ISO 10031 (DOA).  (I haven't
gotten round to reading about DFR yet.)  Note that this would _not_
involve changing SGML; it would be saying that a PUBLIC reference is
a human-readable shorthand that expands into a reference to somewhere
in the SGML-entity subset of all referable objects.
From: LJM@SLACVM.SLAC.STANFORD.EDU (Len Moss)
Newsgroups: comp.text.sgml
Subject: Is there an SGML FAQ list?
Date: 28 Aug 92 23:25:57 GMT
Organization: Stanford Linear Accelerator Center

Hi.  I'm new to this group and, in an effort to avoid embarrassing
myself, I'd like to ask just one Frequently Asked Question:

  Is there an SGML FAQ list, and if so, how can I retrieve it?

(Hmmm...maybe that was really two questions ;-)

Thanks in advance.

--
Leonard J. Moss <ljm@slac.stanford.edu>   | My views don't necessarily
Stanford Linear Accelerator Center, MS 97 | reflect those of SLAC,
Stanford, CA   94309                      | Stanford or the DOE
From: SGML@ifi.uio.no (Erik Naggum)
Newsgroups: comp.text.sgml
Subject: Re: Path Specification in External Entity Declarations
Summary: If you use system identifiers, you ask for problems.  These
	 problems disappear if you use (formal) public identifiers.
Date: 26 Aug 92 19:46:19 GMT
Organization: Department of Informatics, University of Oslo, Norway

Eliot,

I think the problems you have (and must have in any heteregenous
environment) speak out for using (formal) public identifiers, and let
the entity manager worry about where the files are located and what
they're named, if files they be.

My solution to this problem has been presented in this newsgroup (see
article <23243A@erik.naggum.no> in the archive), and includes using a
special (non-SGML) markup declaration at the head of all entities both
in storage and in transit which makes each file self-identifying with
respect to its formal public identifier.  This markup declaration is not
passed to the SGML parser, but is eaten by the entity manager.  A
special program prepares a file (e.g. entities.dir) which contains a
mapping between formal public identifier (from scanning the file), and
the file name (from the file system) in each directory.  Using a list of
directories (path) in an environment-like variable, the entity manager
read these files at start-up, and public text entities can then be
retrieved with a minimum of fuss.

E.g., a file can start with the following "public text identification
declaration" (not an SGML term), and can have any random name it wants,
because the entity manager will use the mapping table, and not the file
name.

    <!PUBLIC "-//Erik Naggum//DOCUMENT Richtext and SGML (v4)//EN">

Note that by using the "unregistered owner identifier" prefix, "-//",
you can use formal public identifiers without bothering with getting a
full registration according to ISO 9070.  (Having an ISBN publisher
number helps organize things, though.)

Also note that system identifiers cannot be expected to work when you
export the document, and may have to be changed for a number of reasons.
A formal public identifier can stay the same because it's a string drawn
from a known and limited character set (minimum data).

I regard system identifiers on par with processing instructions in
cluttering up things, but see that they could be useful on occasion, and
should thus not be deprecated unconditionally.  I also think all public
identifiers should be formal public identifiers.

Conclusion: public identifiers were designed to solve this problem, and
does.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.
Newsgroups: comp.text.sgml
From: tonyb@alf.pec.co.nz (Tony Bray)
Subject: Re: Is there an SGML FAQ list? 
Organization: Production Engineering (NZ) Ltd.
Date: Mon, 31 Aug 1992 04:39:23 GMT
Keywords: SGML FAQ

In article <92241.152557LJM@SLACVM.SLAC.STANFORD.EDU> LJM@SLACVM.SLAC.STANFORD.EDU (Len Moss) writes:
>Hi.  I'm new to this group
>  Is there an SGML FAQ list, and if so, how can I retrieve it?
>Thanks in advance.

Please could you also let me know. I have a further problem in that I
can not FTP from this site.
Would someone be kind enough to EMail me the file.

Tony Bray
Senior Technical Writer
tonyb@pec.co.nz
PEC (NZ) Ltd, P.O.Box 308, Marton, New Zealand



Newsgroups: comp.text.sgml
From: mxm@ornl.gov (MASON J D)
Subject: Re: External Entities and Public Identifiers
Keywords: structured names, iso9070
Organization: Oak Ridge National Laboratory
Date: Mon, 31 Aug 1992 20:19:45 GMT


The question of universal naming schemes for objects has been the
recipient of much attention in ISO/IEC JTC1/SC18 (and elsewhere in JTC1,
too). Unfortunately, there is not universal agreement on what properties
a naming scheme should have, where it should be rooted, how should
manage it, or how a registration authority should be constituted. The
directory-distinguished names of X.500 and other messaging standards
have been cited as one potential model. However, other folks inthe
standards business, who have different sorts of things to name than
nodes on an electronic mail system, have felt that the X.500 scheme did
not meet their requirements. Among the people in SC18/WG8, those dealing
with type-font and character/glyph identification, in particular in
relationship to ISO 9541/ISO 10036 (Font and Glyph identification and
registration) and DIS 10180 (SPDL) have felt that X.500 is inadequate.
One response has been to revise ISO 9070 to be a generalized
registration/naming standard, rather than just something that applied to
"SGML Public Text". One problem in naming is that there is a tension
between the need for a universally understood scheme and the need for
individuals (like the creators of SGML documents) to be able to produce
identifiers without having to call some Registration Authority in Geneva
for a fully qualified structured name. The revised 9070 attempts to
accommodate both needs and further provides a means for mapping between
the sorts of Public Identifiers we have become accustomed to in SGML
with the Object Identifiers used in ASN.1

(This is not to say that 9070 is the final word in naming. I have often
observed that in discussions of naming two groups of standards
developers will wind up using the same vocabulary to talk about entirely
different subjects.)

James D. Mason
Convenor, ISO/IEC JTC1/SC18/WG8
masonjd@ornl.gov



C
D
D
D
obsered
From: robertw@informix.com (Robert Weinberg)
Newsgroups: comp.text.sgml
Subject: SGML <> FrameMaker
Date: 28 Aug 92 19:25:15 GMT
Organization: Informix Software, Inc.

I'm sure this is a FAQ, but I can't get hold of the FAQ from my site so I'd  
appreciate your indulgence.

What filters exist for translating SGML documents to FrameMaker, and visa-versa?

Much thanks in advance! E-mail preferred, I will summarize for the net.

--
+================================+================================+
|         Rob Weinberg           |  Workstation publications tech |
|   Email : robertw@informix.com |        Graphic designer        |
|   Voice : 415-926-6754         |     <imagine your ad here>     |
+================================+================================+
From: jpl@nrtc.northrop.com (Jeff Lankford)
Newsgroups: comp.text.sgml
Subject: Re: Path Specification in External Entity Declarations
Date: 29 Aug 92 00:02:50 GMT
Reply-To: jpl@nrtc.northrop.com
Organization: Northrop Research and Technology Center
Keywords: SDIF, SGML External Entities


In article <23320F@erik.naggum.no>, SGML@ifi.uio.no (Erik Naggum) writes:
|> I see nothing in the standard which precludes having entities whose
|> entity text has different values each time it's referenced.  However,
|> I also see nothing in the standard which says that the entity manager
|> is not allowed to cache the entity text, but must access the physical
|> storage of the entity each time.  In fact, a pretty good case can be
|> made for requiring entity texts to be static with respect to an
|> invocation of the parser.
|> 
|> 4.13 SDIF unpacker:  A program that decomposes an SDIF data stream into
|>      its constituent entities.
|> 
|>      NOTE -- If necessary, the SDIF unpacker will modify the system
|> 	  identifiers of markup declarations to be consistent with
|> 	  storage addresses in its environment.
|> 
	It is interesting to note that given the current standard,
	use of SDIF restricts the flexibility of SGML external
	entities pointed out in the first paragraph.

	The restriction with SDIF arises as follows: SDIF scans an
	SGML document, retrieves the "current" content of each
	external entity and produces a formatted data stream that
	contains the document, the external entity contents and a
	"table of contents" mapping the entity contents to external
	names.  Note that the mapping is such that there is a
	many-to-one mapping between external name reference and
	content; hence, as noted in the first paragraph "... entity
	texts are static with respect to an invocation of ..."
	the SDIF application.

	SDIF "externalizes" the mapping function of SGML entity
	managers, providing in effect a portable entity manager.
	The caveat is that some SGML flexibility is lost, in that
	ported entity content is no longer capable of, as noted
	from paragraph one, "having different values each time it
	is referenced".  For example, a legitimate SGML entity is
	a random number server process that returns a random integer
	for each reference.  When packed by SDIF, each declaration to
	this entity by an SGML document will point to a single
	content instance (all references point to the same number,
	for this example).  Hence, when unpacked and parsed,
	the SGML document will NOT show random numbers!

	External entity portablity is a tough issue, and the SDIF
	solution is an unsatisfying compromise between feasability
	and desirabilty.  In the above example,
	what is desired is some means of migrating the entity
	(process) that generates content, rather that an instance
	of the content.	This area clearly should be reviewed by the
	SGML standards committee, although perhaps no better
	alternative will emerge, though Object Request Broker
	technology should be influential in this area.
jpl
From: jem@hpcupt3.cup.hp.com (Jim McCauley)
Date: Fri, 28 Aug 1992 16:52:35 GMT
Subject: Re: Change bars in SGML
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.text.sgml

Since SGML involves some level of _structural_ description, how might
it be used to indicate structural changes to a document?  For example,
if the sections in a chapter are reordered, how might that "delta" be
encoded in SGML?

Or should it be encoded at all?  Currently, I have to produce a
separate text-description of such changes to reveiwers.  Could this be
automated in any useful of meaningful way?

Even if it should and can, their are interesting problems related to
this.  Simply submitting an original and a radically-resequenced
revision to an automated tool (like `diff') is pointless.  Should the
editing tool itself capture and record changes in sequence (for
example, noting movements of large blocks of text) by means of some
encoding in the revised text?

Finally, how should changes in sequence be presented to the reader?
Simple bars will not do -- perhaps some change-barred version of the
table of contents would be appropriate.

Jim McCauley, Learning Products Engineer    **   I do not speak for   **
(that means that I write documentation)     ** Hewlett-Packard in any **
jem@cup.hp.com                              **   official capacity.   **
Newsgroups: comp.text.sgml
From: tfj@apusapus.demon.co.uk (Trevor Jenkins)
Subject: Status of adjunct standards? (SPDL; DSSSL)
Distribution: world
Organization: Job hunters use Parachute
Date: Thu, 3 Sep 1992 22:35:02 +0000

It's several years since I was actively involved in SGML and in the interim
did not keep up with the work on the other standards. I'd appreciate
knowing ``where they are at'' now as I'm picking up the threads on this and
want that to be a fairly quick process.

-------------------------------------------------------------
Trevor Jenkins                                   Radio: G6AJG
134 Frankland Rd, Croxley Green, Rickmansworth, WD3 3AU
email: tfj@apusapus.demon.co.uk
phone: +44 (0)923 776436
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: External Entities and Public Identifiers
Date: 28 Aug 92 17:36:27 GMT


I wrote:

>Note too that SDIF interchange cannot be reliably implemented
>between systems that have different filesystem structures
>unless they share a common entity declaration convention.
>Such a convention is outside the scope of SGML or SDIF
>definitions and is thus application-dependent.

Both Charles Goldfard offline and Erik N. online made me see the
error of my ways.  The above statement is in fact not strictly
true.

However, it is true to the degree that your non-SGML processes
(file management, human sanity, etc) depend on certain filename
structures and conventions.  To the degree that conventions and
structures need to be preserved, then SDIF is not sufficient without
extra-SGML conventions and processing.  However, that does not in
any way diminish the utility of SDIF, because that problem exists
independently of SDIF, it's just that SDIF doesn't solve it completely.

However, Erik's comments about public identifiers are well taken, and
he's 100% correct.  However, until SGML processing becomes a standard
part of most operating systems, most SGML users will still be working
with real filenames on their local system.  To use IBM as an example,
as we start to build SGML-based systems and processes for managing
information objects, we can start to build into those systems and
processes support for public identifiers so that such support is
consistent and ubiquitous, but that will take time.  In the mean time,
I, Eliot Kimber, am faced with the immediate problem of supporting the
development of SGML-based information across multiple operating
systems with widely differing filesystems using different tools of
varying support for entity management.

My frustration is not with SGML, but with the fact that until support
for SGML is provided ubiquitously, specifically by providing a parser
and standard entity manager on all operating systems, I can't really
take advantage of the full entity management function that SGML
defines and enables.

In analyzing the problems we have within IBM in terms of doing enterprise
publishing of IBM customer documentation using SGML-based systems
and methods, it didn't take long to realize that the big hole is
file management (or more generically, information object management),
and that the only rational solution was one that was built around
a ubiquitous SGML entity manager that provided data access services
for all parts of the system, from authoring tool to downstream batch
processor.  The definition and use of public identifiers will be a key
part of making such a system work.

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: jpl@nrtc.northrop.com (Jeff P. Lankford)
Newsgroups: comp.text.sgml
Subject: Re: SGML in TUGboat
Date: 28 Aug 92 23:09:55 GMT
Reply-To: jpl@nrtc.northrop.com (Jeff P. Lankford)
Organization: Northrop Research and Technology Center


In article <ROBIN.92Aug24164858@utafll.utafll.uta.edu>,
robin@utafll.uta.edu (Robin Cover) writes:
|> I noted four articles pertaining to SGML in the most recent issue of
TUGboat:
	I haven't read those articles, but during the past year SGML
	related articles have appeared with greater frequency in
	TUGboat.  A consensus is growing for a synergy between the
	two:  SGML offers a more formal discipline for describing the
	logical structure of content, while TeX provides a means to
	layout the structure.  Formally associating the two is an area
	of current investigation; techiques using FOSI have been
	proposed, and presumably DSSSL supports a similar approach.

	For academic/technical journal publishing, TeX is de rigueur.
jpl
From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: Revision Bars and SGML
Date: 28 Aug 92 17:39:18 GMT


William Skyvington writes:

> My question is no doubt naive, because I'm a newcomer to SGML.
>
> I'm curious to know how change bars should be handled in a
> politically-correct SGML manner....

This is, as Erik said, a tough nut.

The approach I'm taking is that things like revision status, level,
version, etc., are properties of elements, and are thus carried as
metadata (see my article in the August <TAG> on attributes and
metadata), specifically, as attributes.  By doing this, you separate
the description of the property from any particular expression of it
(e.g., change bars) and you remove the need for sequential processing
of your information to correctly find boundaries of the sort defined
by a <REV START> <REV END> construct.

Say we have, for example, an attribute for all elements called
"REVISIONS=", defined like so:

<!ATTLIST %allGI; revisions IDREFS #IMPLIED -- points to revision
                                               definition elements -->

(The revision definition elements would define the details of a given
revision (say date, reason, author of the revision, related
documentation like change requests, etc.).)

An online system can now enable a query function that shows
all elements that match a particular revision.  It could generate
a list or simply suppress all elements that don't match.  Likewise,
an authoring system could manage the revision information in
an object-oriented way, rather than having to track the beginning
and ending of revision markers that might cross element boundaries.
A print system would simply generate the formatting controls
needed to get the rev bars for each new revised element.  The
visual effect would be identical to using marker elements.

More complex conditional processing can be handled the same way,
especially if you define in your application rules for property
inheritance (for example, all children inherit the relevant
property values of their parents).  Note that ISO 8879 does not
define such inheritance.  Note also that the processing application, not
the SGML parser, has to provide the processing semantics to do
useful things with the property values.

Like Erik, I've used marked sections to do conditional processing.
It works, but it can be difficult for authors to manage "by hand".
Note that one of the features of SoftQuad's Author/Editor product
that really impressed me is its direct support for marked sections
managed by parameter entities.  A/E provides an interface for
defining parameter entities for use in marked sections and then
uses the values of those entities to display or suppress
marked sections during editing.  This is a really nice function.

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