On Wednesday, November 24, 2004, 7:32:59 AM, Bjoern wrote:
BH> * Chris Lilley wrote:
Its much more productive to fix RFC3023 to not be in conflict with Web
Architecture which (as co-editor) i am involved in doing.
BH> If your goal is to feel good when ignoring reality then that may be so,
BH> if you are more concerned about interoperability of running code, which
BH> is slightly more common in IETF discussions, then maybe not.
Bjoern, that seems uncalled for. Lets try to be civil here. I don't
describe your proposals as fleeing from reality, please do me the same
courtesy. And my reasoning in all of this is, of course, existing
implementations and interoperability.
BH> Your pro-
BH> posals so far render all applications for which RFC3023 would be rele-
BH> vant non-compliant regardless of whether they implement only some part
BH> of RFC3023, the entire specification or implement it not at all.
That is incorrect. You seem to miss that once RFC3023 is updated to
ensure that the encoding and the charset are the same, the *sole* use of
a charset parameter is for non-xml applications.
BH> Some of your proposals even
BH> seem out of scope of RFC3023bis as they in essence make it a fatal error
BH> as defined in XML 1.0 if higher-level protocol information affects the
BH> detection of the character encoding of the XML entity which contradicts
BH> XML 1.0. It rather seems you want to change the XML specifications in
BH> which case you should talk to the W3C XML Core Working Group.
No, you mis-state my position. Incidentally, since you bring up the XML
Core WG, you realise that the text I cited in the ASrchitecture document
was written by Tim Bray, co-editor of the XML specification?
BH> Of course, assuming that I actually understand your proposals,
I suspect that you do not, which would explain both the content and the
tone of your comments.
BH> none of
BH> them has really been clear yet, you sometimes give the impression that
BH> the requirements your propose to add to RFC3023bis just render some
BH> content non-compliant without any actual effect on conforming
BH> implementations, that would then be even worse as it would have no
BH> effect in practise other than complicating theory even more. In fact,
BH> in that case one would even wonder what you are actually trying to
BH> achieve, as RFC 3023 already states
BH> Processors generating XML MIME entities MUST NOT label conflicting
BH> charset information between the MIME Content-Type and the XML
BH> declaration.
And thus, what use is the redundant declaration? Note that currently
there is great variability in what processors do when reading and saving
content that has conflicting declarations. Removing the source of the
conflict brings us onto safer ground to the area where all
implementations behave the same. Surely you can see that this is good
and results in more robust, interoperable behavior?
I am frankly puzzled by your insistence on retaining the woolly
non-interoperable area while simultaneously claiming that i am
unrealistic and do not care for interoperability.....
--
Chris Lilley mailto:chris(_at_)w3(_dot_)org
Chair, W3C SVG Working Group
Member, W3C Technical Architecture Group