Re: B.1 and B.2 results

paul@arbortext.com (Paul Grosso) writes
> > ...
> > 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.

Sorry, I was too elliptical It would make sense to have a new type,
for the sake of argument HOSFILE, which would be the default if you
didn't provide a type, meaning OSFILE with prefix header to be
processed and NOT set to the XML application as data.  The option to provide
an explicit type would allow you to use OSFILE as you point out it is
specified, with the additional requirement for XML that the default
encoding is implied for type OSFILE (and any other type without
provision for out-of-band meta information).