🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

3 total messages Started by "Dr. "Eliot Kimber" Macro" Fri, 28 Aug 1992 17:36
External Entities and Public Identifiers
#159
Author: "Dr. "Eliot Kimber" Macro"
Date: Fri, 28 Aug 1992 17:36
56 lines
3439 bytes
References: <9208242114.AA13720@ucbvax.Berkeley.EDU><23320E@erik.naggum.no>

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
Re: External Entities and Public Identifiers
#162
Author: Alasdair Grant
Date: Fri, 28 Aug 1992 19:44
12 lines
1213 bytes
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.
Re: External Entities and Public Identifiers
#172
Author: MASON J D
Date: Mon, 31 Aug 1992 20:19
41 lines
2395 bytes
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 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads