[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The Browser Wars are Dead! Long Live the Browser Wars!


datastore browser

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.