- From: Gavin Nicol <gtn@ebt.com>
- Date: Wed, 18 Sep 1996 21:05:19 GMT
- To: ricko@allette.com.au
- CC: U35395@UICVM.CC.UIC.EDU, w3c-sgml-wg@w3.org
>> The point is that in your scenario, the entity manager must be smart >> enough to sniff at the data to figure out how to parse it. With >> MIME-SGML, SGML across HTTP, and other such things, it seems to me >> that most XML entity managers will be supporting MIME anyway... > >Not the SGML entity manager when the XML file is read as SGML, since it >won't use the PI. It can just use the plain file as is, or be aided by >FSIs or whatever if needed. (If there is no requirement that XML files >can be read directly as a (head-less) SGML instance, then I completely >defer to you, by the way.) This is my point. You *cannot* read the entity in unless you know the coded character set and encoding. The entity manager therefore must either understand the PI hack, or some other external mechanism (FSI, MIME, etc). If the entity manager doesn't understand the PI hack, then what's the point of having it? >The header that looks like a PI is trivial to convert into one that looks >like the MIME header. So a XML entity manager could implement reading >local XML files just by doing that header translation and submitting the >file to itself as a MIME type. So their needn't be a duplication between >MIME decoders and ones selectable by the PI. (Or, conversely, an XML entity >manager could convert an text/xml header into a PI if it that was more >convenient for the implementor.) I don't see the point in duplication. One way or another, you either use the PI hack alone, or together with some other external labelling method. In the latter case, the external labelling method alone suffices.
Received on Wednesday, 18 September 1996 17:06:46 UTC