Hi all, On Fri, Sep 25, 2009 at 1:49 AM, Kevin Smith <kevin at kismith.co.uk> wrote: > I don't have anything to add to this discussion, I'd just like to > plant my flag in the "Show me some benefit to this before we consider > breaking a large proportion of running server code" camp. > Ok I don't really know what to answer now. The fact is that I understand your answers and your reasons. There appears to be some kind of "heavy" optimizations on some current usage which requires apparently to be very liberal with XML (the example of just checking first letter for instance). After this I still wonder, first, of much these optimizations are that efficient compared to a more common parsing method. But this is not that easy to say, so let's not make a point of it... Furthermore I wonder how much they can be considered "good" (but "good" is often a pretty subjective word, even on technical topics). On a strict "good design" point of view, the first-letter-check for instance seems to me far too liberal on the strictness of XML. As Peter said on his last email "Not that that's the right thing to do, mind you.". But still it exists. And apparently on at least 2 implementations, as Joe said. So we don't want to break this. It is clear. Then I would say 2 things: 1/ Still I know there are still a lot of softwares doing normal parsing/reserialization. For them the modification would not be that hard (remove the additional tests). Moreover it looks to me that these restrictions are helpful to implementations wishing to make such kind of very big shortcuts/optimizations (like checking a single byte instead of a whole name) but are at the opposite a burden for the ones which don't (making additional tests. That's not like very big burden, but still it is useless). 2/ It is not as though it would suddenly break all implementations. The RFC should still recommend (with SHOULD) to have a prefix named "stream", to define it in the opening stream tag, and to have a default namespace in this same tag. And people will most probably follow these recommendations anyway, at least because they don't want to be broken against some big servers using old implementations. But at least the RFC is clean (I like clean designs) and this kind of checks can be slowly removed from code bases in time (and never made on new codes). No need to hurry. No need any "code camp". That's not going to change our lives or make all implementation suddenly obsolete. It will be just a "minor bug" which probably will never be noticed by users. But if that's not enough, I don't know what to say more. Bye. Jehan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.