Cart
|
[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!
 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! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
