Re: Limited modified eclectism (was Re: Reads like ASCII)

>1) File can be valid SGML (as external general entity) 

True for systems that understand the hack. For systems that do not
understand the hack, they will still need an external way of
indicating the encoding.

>2) File can be a canonical storage form, does not require any external 
>labelling.

When I say external, I	mean external to the actual entity. Metadata
does not belong in the objects that it refers to.

>3) Encoding can be determined merely by looking at the header with any
>standard tool that can do an ascii dump of a file (UNIX od, DOS Xtree,
>etc)

For only a limited set of encodings. Equally true for *.mim.

>(or even strip out the PI and reinstert it when the data is stored).
>Perhaps there are two different needs here that are reconcilable:
>MIME systems need MIME headers, SGML systems accept dumb plain text
>files. If the PI was transformable into the MIME header and back,
>both needs are met.

I'll give you one more reason to favor *.mim.

Many SGML systems, and probably most XML systems, will have the
ability to use the HTTP protocol to retrieve entities (SP already has
this capability). This effectively means that they must have the
ability to parse HTTP headers, which have exactly the same syntax as
the *.mim file format headers. There is a lot of *free* code for
parsing MIME bodies.

FSI's also provide an equivalent functionality, and we should probably
encourage deployment of them. However, this code will be more specific
to XML/SGML.

Summary of *.mim benefits:
   1) Compatability with HTTP/MIME
   2) Free code libraries (PERL, TCL, C, C++, JAVA)
   3) Extensibility (you can add other parameters like
      Content-Encoding)
   4) Doesn't confluge data and meta-data
   5) Isn't a hack.

Received on Tuesday, 17 September 1996 09:07:43 UTC