Thread View: comp.text.sgml
3 messages
3 total messages
Started by "Dr. "Eliot Kimber" Macro"
Fri, 28 Aug 1992 17:36
External Entities and Public Identifiers
Author: "Dr. "Eliot Kimber" Macro"
Date: Fri, 28 Aug 1992 17:36
Date: Fri, 28 Aug 1992 17:36
56 lines
3439 bytes
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
Author: Alasdair Grant
Date: Fri, 28 Aug 1992 19:44
Date: Fri, 28 Aug 1992 19:44
12 lines
1213 bytes
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
Author: MASON J D
Date: Mon, 31 Aug 1992 20:19
Date: Mon, 31 Aug 1992 20:19
41 lines
2395 bytes
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