W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: B.1 and B.2 results

From: Paul Grosso <paul@arbortext.com>
Date: Wed, 23 Oct 96 08:46:06 CDT
Message-Id: <9610231346.AA12314@atiaus.arbortext.com>
To: w3c-sgml-wg@w3.org
> From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
> Date: Wed, 23 Oct 96 09:54:51 BST

> David's observation that "[Since] SGML has the general notion of an
> entity manager, the notion of an entity header on the storage object
> fits right into the SGML model" seems to me to be exactly right.  Step
> back a minute and think what you expect the command line argument to a
> Unix-based XML tool to be -- a filename?  a filename or a URL?  a
> filename or a URL or an FPI?  Well obviously, it's going to be,
> implicitly or explicitly, just as for SP-based applications already, an SGML
> Open entity specifier, that is, any of the above.  Which means that
> rudimentary entity access management is a necessary part of any XML
> application, and for entities of type OSFILE that means finding the
> header information on the front thereof.  Is that really so bad?

I must be in possession of a different set of data.

In my book, "osfiles" have no header information, and the "storage
object identifier" on the right hand side of an SGML Open TR9401 catalog
is the name of a file, all bytes of which gets sent to the SGML
parser.  So, I would expect most existing SGML systems would need to
be modified to process files that are "headed" by data that are not
supposed to be sent to the SGML parser.
Received on Wednesday, 23 October 1996 09:53:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC