19.7.06
Revealing the X/O impedance mismatch
Ralf Lämmel and Erik Meijer explain why its hard to mix angle brackets with curly brackets.
Abstract
When engaging in X/O mapping, i.e., when viewing XML data as objects or vice versa, one faces various conceptual and technical challenges~---~they may be collectively referred to as the `X/O impedance mismatch'. There are these groups of challenges. (i) The XML data model and the object data model differ considerably. (ii) The native XML programming model differs from the normal OO programming model. (iii) The typical type systems for XML and objects differ considerably, too. (iv) Some of the differences between data models and between type systems are more like idiosyncrasies on the XML site that put additional burden on any X/O mapping effort. (v) In some cases, one could ask for slightly more, not necessarily XML-biased language expressiveness that would improve X/O mapping results or simplify efforts.
The present article systematically investigates the mismatch in depth. It identifies and categorizes the various challenges. Known mitigation techniques are documented and assessed; several original techniques are proposed. The article is somewhat biased in that it focuses on XML Schema as the XML type system of choice and on C\# as the OO programming language of choice. In fact, XSD and C\# are covered quite deeply. Hence, the present article qualifies as a language tutorial of `the other kind'.
Abstract
When engaging in X/O mapping, i.e., when viewing XML data as objects or vice versa, one faces various conceptual and technical challenges~---~they may be collectively referred to as the `X/O impedance mismatch'. There are these groups of challenges. (i) The XML data model and the object data model differ considerably. (ii) The native XML programming model differs from the normal OO programming model. (iii) The typical type systems for XML and objects differ considerably, too. (iv) Some of the differences between data models and between type systems are more like idiosyncrasies on the XML site that put additional burden on any X/O mapping effort. (v) In some cases, one could ask for slightly more, not necessarily XML-biased language expressiveness that would improve X/O mapping results or simplify efforts.
The present article systematically investigates the mismatch in depth. It identifies and categorizes the various challenges. Known mitigation techniques are documented and assessed; several original techniques are proposed. The article is somewhat biased in that it focuses on XML Schema as the XML type system of choice and on C\# as the OO programming language of choice. In fact, XSD and C\# are covered quite deeply. Hence, the present article qualifies as a language tutorial of `the other kind'.
Comments:
<< Home
distinguishing dual concepts of "optionality" and "mandatoriness"?
I think that says it all about this paper, really.
I think that says it all about this paper, really.
It seems Theo (?) ended up thinking that we are talking about the trivial tension between optional vs. required (mandatory) particles. Instead, this duality is about the concept of optionality (in the sense of expressing explicitly optional particles) vs. the concept of not expressing optional particles but instead expressing explicitly required particles (so as to assume implicit optionality whenever mandatoriness is not made explicit). I still agree that this is stretching the meaning of duality (http://www.thefreedictionary.com/Dual) a bit, but I am not yet sufficiently embarrassed to start editing the file; I am still exhausted from the last round. More items for the TODO list very much appreciated.
OK, well, first of all, sorry for my rudeness in posting like that!
I did understand that part of the paper correctly, however. To try to make a more constructive criticism:
"Dual" suggests to me some kind of non-trivial or at least interesting mapping between the two concepts. In this case, optionality is just the negation of mandatoriness (just as optional is the negation of mandatory). I guess you might talk about them as complementary concepts. (it would be a stretch to say "inverse", I think.)
So I sort of felt that this was over-elaborating the issue. They're the same concept, essentially, so I sort of felt it was perhaps too indulgent (and not reductive enough) to give them separate status.
In a way I feel this is symptomatic of a larger issue, which is that placing the "impedance mismatch" at the centre of your study tends to result in a much more subtle and complex situation (trying to build a generic adapter) than, say, focussing on similarities and trying to find a simple but still expressive common sublanguage.
My interest in reading Philip's blog is primarily to follow possible directions for Links, so in part by commenting on the paper I wanted to give a tiny push towards a pragmatic approach (a mapping O/X where X = particular subset of xml, for example). I feel, and perhaps you agree, judging from the conclusions section of the paper, that there is a lot of scope for getting bogged down in this area. (dealing with design flaws in XML standards, in part)
In any case, I see Ehud has now posted this to Lambda the Ultimate, so I guess if there's any further discussion that's the place to take it. t
I did understand that part of the paper correctly, however. To try to make a more constructive criticism:
"Dual" suggests to me some kind of non-trivial or at least interesting mapping between the two concepts. In this case, optionality is just the negation of mandatoriness (just as optional is the negation of mandatory). I guess you might talk about them as complementary concepts. (it would be a stretch to say "inverse", I think.)
So I sort of felt that this was over-elaborating the issue. They're the same concept, essentially, so I sort of felt it was perhaps too indulgent (and not reductive enough) to give them separate status.
In a way I feel this is symptomatic of a larger issue, which is that placing the "impedance mismatch" at the centre of your study tends to result in a much more subtle and complex situation (trying to build a generic adapter) than, say, focussing on similarities and trying to find a simple but still expressive common sublanguage.
My interest in reading Philip's blog is primarily to follow possible directions for Links, so in part by commenting on the paper I wanted to give a tiny push towards a pragmatic approach (a mapping O/X where X = particular subset of xml, for example). I feel, and perhaps you agree, judging from the conclusions section of the paper, that there is a lot of scope for getting bogged down in this area. (dealing with design flaws in XML standards, in part)
In any case, I see Ehud has now posted this to Lambda the Ultimate, so I guess if there's any further discussion that's the place to take it. t
Theo, thanks for getting back on this. First of all, I agree that the discussion of the whole “?/!” issue must be improved in the final version of the paper. Interestingly, there is a non-trivial mapping between optionality and mandatoriness that may fit your bill: optionality cannot be deselected anyhow in a language w/o non-nullable types but then in these languages unavoidable optionality may still need to be distinguished from discoverable, programmatically enforced optionality. By contrast, in a language w/ non-nullable types there is a clear-cut distinction. In fact, we are trying to say that non-nullable types are not pluggable for optional element particles (per trivial inversion), unless we give up on a simple treatment of missing content. When we were writing this piece, this circumstance gave us sufficient headache to end up talking about duals.
Let’s get to your main concern, Theo says: “placing the impedance mismatch at the centre of your study tends to result in a much more subtle and complex situation […] than, say, focus[s]ing on similarities and trying to find a simple but still expressive common sublanguage”. Theo, yes, we could easily work around the problem like this. I can cook up any number of XML type systems that are easy to map. But the X/O impedance mismatch is about existing type systems and the potential of running into their generality: http://blogs.msdn.com/ralflammel/archive/2006/07/19/671595.aspx
Regards,
Ralf
Post a Comment
Let’s get to your main concern, Theo says: “placing the impedance mismatch at the centre of your study tends to result in a much more subtle and complex situation […] than, say, focus[s]ing on similarities and trying to find a simple but still expressive common sublanguage”. Theo, yes, we could easily work around the problem like this. I can cook up any number of XML type systems that are easy to map. But the X/O impedance mismatch is about existing type systems and the potential of running into their generality: http://blogs.msdn.com/ralflammel/archive/2006/07/19/671595.aspx
Regards,
Ralf
<< Home