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@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group