Question: Several remarks on the
RelationalWeenie page lump together
ObjectOrientedProgramming and
ExtensibleMarkupLanguage. Is there a natural fit between the two? Have the relational guys identified a pattern?
They are both non-relational, A.K.A. "navigational" (a combination of graphs and trees/nesting) in relational-speak. Whether that is enough to lump them together probably depends on your world viewpoint. It would probably be easier to map XML structures one-to-one to objects than to relational tables. In that sense, they are somewhat similar.
See
VbClassic section on Enterprise distributed application development for opinion that if these are evils, these are the necessary ones too. --dl
Is there a natural fit between the two?
Well, to state the obvious, the
ExtensibleMarkupLanguage and
ObjectOrientedProgrammingLanguages are similar in that both are capable of expressing the structure (and state) of an object model. But, the complement of the
ExtensibleMarkupLanguage with respect to
ObjectOrientedProgrammingLanguages is executable behavior encapsulated with that structure and state into classes or hierarchies thereof. Therefore it feels mistaken to me to equate them. XML is a markup language. OOPLs are programming languages. I'm sure somebody has already invented a schema for expressing the logic and invocation of object methods in XML, and a machine for executing programs encoded as documents in that schema. But isn't that just inventing a new OOPL using XML syntax? --
RandyStafford
On the other hand, I have seen a columnist who writes about XML supporting views that OO is less suited than functional languages in processing XML data --
MicrosoftSlave
True, but on the argument that
XmlIsaPoorCopyOfEssExpressions then if you've got
LispLanguage, why bother using XML at all? Based on that line, OO would be a natural fit for XML precisely because it's only okay at handling it. There's some stuff about this at the bottom of
SymbioticLanguages.
You have
ObjectXmlMapping s similar to
ObjectRelationalMapping s (with all the attendant controversy) see
XmlAcceptorPattern,
OpenAdaptorXml etc. Sometimes you need all together ie a web application that presents different views to different devices:
[RelationalDatabase]-->[ObjectRelationalMapping]-->[ObjectOriented BusinessLogic]
|
[Desktop,PDA,Mobile Phone]<--[XSLT]<--[ObjectXmlMapping]
XML in my opinion just makes information easier to share between organizations and/or devices by having a standard (better than EDI anyway) but processing should be done by
ObjectOriented code (C++, Java etc). You can have
XmlDatabase or
ObjectOrientedDatabase at the back end but most of what is deployed is still relational (feel free to offer statistics as to how fast this is changing). So you need these bridges between technologies. Hopefully in the future this will converge to something simpler. See also
MultiTierArchitecture.
Not knowing much about Xml, I came across this XML is Too Hard for Programmers claim at http://tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
The writer works at Sun and uses Perl to illustrate his point regarding difficulties encountered, including OO aspects.
There were quite a bit of discussions about that article at http://lambda-the-ultimate.org/classic/message6204.html
Now for my question, why can we not just ignore Xml, and stick to using the tools that work with Xml instead? An example of tool that I have on my mind is WebMethods which is a MiddleWare that interfaces applications from different environments via Xml, but I think the developer does not really need to know Xml --dl
I'm sure somebody has already invented a schema for expressing the logic and invocation of object methods in XML, and a machine for executing programs encoded as documents in that schema.
Yes, it's called SOAP or
SimpleObjectAccessProtocol.
SOAP doesn't support the expression of the logic of object methods, does it? Only their invocation.
This sounds a little like JAXB
http://java.sun.com/xml/jaxb/
CategoryXml