>1. Non-network access
>[This is obvious] a lot of XML files are going to be stored in files
>and accessed by means other than HTTP, and some encoding signalling
>mechanism is obviously required. Also, we wanted something that was
>simple, easy to explain, and could be done by anyone with whatever
>editor they were using.
That is still insufficient justification for the PI hack. You could
have just as easily recommended the *.mim format. I am vehemently
against *data* sniffing. If the PI is a header, say so, and then
give it a different syntax.
>networked computing environment. I, and I'm sure many of the rest of us,
>have enjoyed the beneficial effects of Mime technologies in recent years;
>but if you're doing anything large-scale on the Web, if you rely on
>external metadata/signalling in general, you're dead - or more formally,
>your receiving application will suffer an unreasonable number of failures
>due to various botches and bogosities. The reasons for this are, in my
>experience, a combination of incompetence in website administrators and
>lack of education in document authors.
I cannot see this as justification for the PI hack either. Broken
software is just that: broken. I know, probably better than anyone on
this entire list, what the exact dangers are with WWW content
labelling mechanisms. I also know what the potential is for
correctness, and how to overcome a lot of the bogosity/idiocy.
I do not see the PI hack as a necessary part of this solution, though
I agree with the overall *concept* of having a header (which is what
it really is).
I understand the problem you are trying to solve, and understand how
your answer tries to solve it. I do not think that the problem gives
sufficient justification for the answer proposed, though, and think
that cleaner mechanisms, both semantically, and syntactically, and
both preferrable, and likely to be widely used *irrespective* of XML
Let's not repeat the <META> idiocy here.