Lists Home |
Date Index |
>That's a bit like saying that XML should not be used as marshalling
>information when arbitrary strings are sent around. So should SOAP and
I don't see the problem with SOAP; I don't recall seeing SOAP implementations that break the spec. I'll be the first to admit that certain WebDAV implementations from a company in Redmond are prone to emit broken XML. The same as the database people who say "round-tripping is PARAMOUNT!". I personally have no sympathy at all for this mentality.
>However, ignoring the issue doesn't exactly help either. Many
>applications/protocols are stuck with the task of marshalling "arbitrary"
>strings as XML (and datatype xs:string), so it would be good if there was an
>XML-1.0 compliant, cross-protocol format to do this.
Nobody is saying to ignore the issue. The tradeoff has already been made, and the best anyone can do is just follow the spec. There ARE solutions (base64, using something other than XML, etc.) and I do not think anyone (including Microsoft) should be excused for creating crap and calling it XML. It poisons the wells, and has negative impacts far down stream, as we have seen with numerous XML parsers breaking on so-called "XML" from certain WebDAV servers. If the stuff can't be processed by a single conforming XML processor, there is really no point in calling it XML. And I would disagree with your sentence "Many applications are stuck with the task of marshalling 'arbitrary' strings as XML datatype xs:string". You are in essence saying, "many applications have the requirement to emit something that is NOT xs:string, but call it xs:string anyway". My point is that *no* application has such a requirement; they may *think* they have such a requirement, but that is like saying "I need to be able to store a string in this longint field" -- eventually the developer figures out that maybe that wasn't the right datatype to choose -- maybe a more appropriate datatype would be in oorder.