Ph.D vs the real world

Note: this entry has moved.

In a previous post I showed and discussed the similarities between the W3C XML Schema type system and the CLR one. Dare commented on it by mentioning a number of already known (at least by me) issues with WXS->CLR mappings, specially the fact that the later supports only a subset of the former.
Given the overwhelming response in favor of similarities against differences (1013 to 0 so far), I can only say that Dare is probably ignoring that most developers are .NET DEVELOPERS, NOT XML theorists and WXS fans. Therefore, most of them completely ignore or plainly don't care about the intricacies of WXS he's talking about. My question was about the features developers really use from WXS, and the answers I got speak for themselves.

So, there's no tautological question as he argues. I can rephrase my question as follows: “If you ignore the parts that are irrelevant/impractical (such as no support from XmlSerializer)/overly-complex-to-be-of-any-use/only-for-WXS-fans/Ph.D-only-material, do the CLR and XSD type system fit well together?”. If I ask the people to vote again, I'm willing to bet whatever I have that I will get the same answer.

That's why my weblog is titled "IXml* - Welcome to the real world". Not only because I'm a big fan of Matrix but because I care about what happens in the daily work with XML.

8 Comments

  • In simple scenarios as outlined in my blog there is no problem. In the real world of XML development especially in the world of XML Web Services (not Joe Blow developer using the XmlSerializer as a better way to get values out of his config file which is most of the crowd that read .NET Weblogs) the impedance mismatch is a problem.



    The fact that the limitations of the XmlSerializer are not a problem in the scenarios you have used it does not mean they are not a problem. It just means they haven't been a problem in the limited situations you have applied it.



    On the other hand, myself and the Indigo folks who are responsible for the XmlSerializer have had numerous conference calls and customer requests about these said imedance mismatches.



    Your entire argument is like claiming that since most developers just use elements and attributes that Microsoft should just produce a simpler XML API that doesn't expose CDATA sections, PIs or entities. By the way, I've heard that argument quite a lot as well.

  • I agree completely Dimitre. I was NOT seeking precise answers. I was seeking a practical and pragmatic view of readers. When you want to know what people think and use in everyday development you go and ask. You don't confine to a room to read Priscilla Walmsley's "Definitive XML Schema" (what I'm ALSO doing, BTW). I was not trying to gain confidence on the matter. I don't need that. I just wanted to prove a point: that most of WXS is unused, specially its very features that introduce the mismatch Dare talks about, and the big mayority of developers only exploit it as far as it's easy to map to their previous knowledge of OOP.

  • The conclusion I draw is that WXS type system "fits nicely" with the CLR one. I'm not saying they are an exact match, neither I am ignoring the mismatch. I'm only drawing the conclusion that for most uses (remember the 80/20 rule?), they are pretty similar.

    If you're on the 20 side, they may not fit so nicely. But I'm not concluding they will under all circumstances.

  • Daniel,

    If I were you I'd pay more attention to Dimitre. Erik Meijer sits in an office across from mine and we talk about this stuff all the time (or did you miss my reference to his paper in my blog post?) and he doesn't think they are are compatible as you say. Doug Purdy who was the PM for the XmlSerializer and owns the Indigo XmlFormatter agrees with my position (and said as much in his blog).

    To argue with the people who are designing the very APIs you quote as proving your point is confounding and quite contradictory.

  • Ok, now tell me all the work in XmlSerializer to do the mapping as transparent as possible, as well as the new XmlFormatter don't have anything to do with WXS...

    I have to believe that the theory (even if it contradicts all subsequent acts) is the only thing to trust. Ok... if you say so.

    I just think the world is going to a more seamless integration between both. See where's Java XMLBeans going and the like... Java guys don't even need to resort to a hack like the ObjectXPathNavigator, they have it for free. They can apply XSLT directly to objects, as well as validation. I was faced with this when I implemented Schematron.NET. Eddie Robertsson pointed it out to me. That's a good direction, I'd say

    Now, if you're trying to tell me that I should forget about the mapping because WXS and CLR have nothing to do with each other, them you should make your voice louder, specially through your weblog and the MSDN center, because it looks like many of us got confused by MS message in this regard. Look at the number of XML MVP in my previous informal poll and think about it. They are "XML MVPs", not "Joe Blow" developers. If they didn't get your message that WXS and CLR DONT FIT WELL TOGETHER, I'd say there's something wrong with MS communication strategy. Maybe you should clarify that the XmlSerializer is just a toy for "Joe Blow" for "simple scenarios" and not really of any use in "real world of XML development especially in the world of XML Web Services".

    On the other hand, as I DO believe, if you're on the theory field, I completely agree. The paper you mention (I did see it and, like I said, already read it) is yet another theory explained. I doubt many "Joe Blow" read those things. I do, and I'm sure most XML MVPs also do. Yet, we failed to get the message you're proclaiming. Or maybe it's just that in practice, MS shows how easy it is to map both, but doesn't want to be blamed when they don't fit just so nice?...

  • Daniel,

    This is the last time I am going to bother to post on this topic because it is obvious you are not bothering to read and understand what I and others have written. I'll write the short version for you, there are two ways to think of technologies like the XmlSerializer



    1) Objects to XSD conversion



    and



    2.) XSD to Object conversion



    The XmlSerializer does a good job of (1) modulo some minor issues while it does a poor job of (2). In practice the average developer writing desktop or web apps only does (1). Similarly if they designed an XML Web Service using VS.NET they are also usually doing (1) as well.



    If you are doing (2) then the XmlSerializer is too limited for you due to type system mismatches.



    It seems you are claiming that the people who do (2) do not exist except for Ph.Ds and XML geeks at Microsoft. As I've said before myself and others at Microsoft have talked to a number of big (as in millions of dollars spent on Microsoft products) customers who have this problem. Just because you haven't encountered these problems in the apps you write doesn't mean they don't exist.

  • Last time for me too. All I can say is 80-20.

    That relation is what I see here. That relation is what I (and the others who shared my opinion) would call "they fit nicely". Something that doesn't fit at all doesn't hold that relationship.



    I'm not ignoring the 20, just saying it's a 20. I've read and understood all you and others wrote. I agree almost completely. That has nothing to do with my belief that you're still talking about the 20 range (if not less). The Ph.D may have been an unfortunate comparison with "the real world", but just tell me honestly if you believe the mismatches are more than 20% of concrete use cases/customer problems... I don't think so.

  • How is it that the XmlFormatter has nothing to do with the WXS? The XMlFormatter is all about the WXS -- it is the mechanism to map any serializable CLR type into WXS.

Comments have been disabled for this content.