Re: Encoding PIs recap. (Re: Comments on 31 March spec)
>The PI rationale has been discussed before: if you require a
>particular encoding for the PI, you are creating a non-text header.
>You need special applications. Gavin's .MIM format would be far
>superior than the Encoding PI for this. (I hope that people
>writing storage/entity managers and file systems look at the
I will be re-submitting this to the IETF, and to the W3C as a
technical note within the next week or so. At the recent Unicode
conference, there was a lot of discussion about this...
I should note that one implementation problem that arises from
the encoding PI is that once you start parsing the file to get
the PI, you have to assume an encoding. If it turns out that
the encoding you assumed is not correct, then you have to seek
back to the beginnings of the input stream and restart using
the encoding that the PI told you to use. This is generally not
a large problem if you use a ring buffer, or some other form
of buffered input, but this can force implementation choices that
would otherwise not have been made.