Rant continued: Some reasons...that don't usually apply

  • Article

My previous post on my distaste for encoding XML into strings and passing the encoded strings in the Web service message payload generated some feedback.

While thinking over the possibilities for when it might be acceptable to encode XML, I came up with three reasons that might apply:

1. processing instructions in the XML must be preserved (SOAP doesn't allow PIs in the envelope) or a DTD

2. namespace collisions (you shouldn't have these, but we don't live in a perfect world)

3. situations where a bad app requires the integrity of proprietarily canonicalized XML (again, this shouldn't happen but one could imagine an app depending on certain whitespace representations or something like that).

You could probably think of a couple others that are similar.  There really isn't an excuse for #2 or #3, but I could see scenarios where #1 could be legitimate.  But obviously it does not apply to the vast majority of Web service scenarios.

I'm pinging some Microsoft internal CRM folks to see if they have an explanation why they do this.

   -Matt