[
Lists Home |
Date Index |
Thread Index
]
On Tuesday, October 22, 2002, at 11:15 PM, Paul Prescod wrote:
> No, the structure of the request and the response is generally
> completely unrelated to the underlying structure of the data store. In
> fact, the structure of the request and the response is ideally an
> international standard like SVG, RSS, HRML, ebXML etc. This structure
> is unrelated to the databases you use to structure it.
Can't be true.
The request must name elements in the underlying data store and
enumerate at least part of the their relationship and optionally
specify the format of the output. You both expose underlying store
structure in a request and specify.
SELECT t1.first_name, t1.last_name, t2.country_name FROM t1 user, t2
locale WHERE t1.locale_code = t2.locale_code;
If I see enough of these queries I can fully deduce the underlying
structure of the data store. They are more than related - they are
tightly coupled. XSL transformation rules are similar. I can deduce
much of the structure of the underlying XML document from the XSL style
sheet. Furthermore I know that the output format is a 3 column tuple
with content positionally described. So there is no loose coupling at
this level. Its very tight.
Now, if you want to argue that the XML being described is removed from
the underlying datastore that produced it. Sure. Two transformations
produce some flexibility but any one transformation is brittle with
respect to the datastore on either side of it.
So I remain unconvinced of the benefits. As far as I can see, its the
same.
> The basic idea of an object is to wrap up some data with some methods
> (behaviour). The basic presumption is that the person providing the
> data knows enough about what the person using it wants to do to
> provide the correct and complete behaviours. But typically in
> networked applications that is not the case. It is better to just
> separate the data from the behaviour and let the client associate
> whatever behaviours it wants.
So you want an interchange format. There's nothing wrong with that.
I'll go so far as to say that a universal object interchange format is
a good thing. A way to serialize object networks that is useful for
data interchange is a good thing.
But XML doesn't look anything like what you would get if you were to
serialize a network of objects. Its quite different. Worse, the
object to XML serialization scheme is open to interpretation in a big
way. (I know attributes vs elements is an oldie - and I don't want to
respark debate). The mapping between XML and say ER models isn't very
clean or well defined. Too many homegrown ideas running around and
the mapping problem makes the so-called Object-Database impedance
mismatch look minor by comparison.
> Plus there are many technical issues with passing around mobile
> objects: denial of service, analysis is difficult because of Turing
> completeness issues, "secure" virtual machines usually have bugs,
> cache semantics are really tricky, etc. etc.
This issue has been solved other ways. Any ER or OO information model
can be completely described using arbitrary nestings of Maps
(Dictionaries for Smalltalkers), Lists, and Strings. If you like you
can provide a little extra support for automatic coercion for numbers
and dates. There is absolutely no piece of information that can't be
represented with this small set of primitives. NextSteppers call these
PLists (property list) and its really easy to rebuild an object/data
network from a plist. In fact, its easy to automate.
I don't see the same thing with XML. Instead we get the DOM - which
doesn't look like any other datamodel used to represent information
ever used in the history of information modeling - oh yeah - except for
HTML-ish syntax. But HTML was a hack. Now the hack is enshrined.
> I don't see a circle closing. XML is, as far as I know, the first
> universally used information interchange format. It certainly is not
> analogous to either Smalltalk or SQL.
No, that would be card image format (line oriented if you like) ascii.
The next one would be RFC 822 messages. And XML is not yet universally
used - its only universally buzzed about. I have yet to adopt it for
anything practical at all because I'm still walking around and around
it saying to myself "what could have possibly lead them to THIS?"
Todd Blanchard
|
