Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
 Paul Prescod wrote: > If I am using a DOM interface, > it frankly > > doesn't matter what the serialization format is, I am > interacting directly > > with data through an interace. > > You are interacting with data through an interface that was designed to > provide access to the abstract data model of a *serialization*. In other > words you are treating your database as if it were the result of parsing > an XML document. You've put an "elements and attributes" interface on data > that is much more complex than elements and attributes. If it were not > more complex then elements and attributes we would not need stuff like > XLink, HyTime, Namespaces and RDF to even *attempt* (and fail) to > represent it. Really !? and I thought I was interacting with an interface designed to represent the abstract data model of XML. How could we have drawn such disparate conclusions. I *don't* care what the intention of creating the DOM interface was BTW just as I don't care what the intention of creating the C language was. I can use tools, interfaces as I see fit. Does the DOM represent XML data in full fidelity? If not, should it be extended? I'm not sure that the data is so much more complex than can be represented by the DOM interfaces. Perhaps I have a different view than you do. The way I see it, I can represent pretty much any piece of data using XML as I can with say an s-expr. The issue is only one of efficiency (as it has been with s-exprs). So, as I see it, if I put an efficient implementation behind an interface, it might work in ways you haven't imagined. > The XML data model, whether a grove or a DOM is the "Forrest > Gump" of representations for your data. Sending a dumbed-down message by > Forrest Gump is good: he will relate it faithfully. Installing him as the > only conduit for information is bad. You'll have to dumb down too much > information and spend too much energy re-assembling it on the other side. Really? And what is a more intelligent abstract data model? I'm not feeling too limited yet but perhaps I'm doing simplistic stuff. SGML has been around for years, but has never generated too much excitement. In contrast, XML. Sometimes simple is very very good. Sometimes, the simpler things get the more powerful they get. > > > I wouldn't suggest that the DOM replace ODBC, yet I'm > quite sure that those > > experienced using a variety of systems with disparate data > types and data > > usages will appreciate that certain types of data are best > expressed in tree > > format. Such data scenario's might best be interfaced with via the DOM. > > You just need an API for "tree formats". Just ask your DBMS vendor to > provide some tree-structured API. It doesn't matter if that API is the DOM > because making it the DOM does *not buy you anything* as a programmer. > From a programming point of view there is no benefit to working with a > consistent API where everything is dumbed-down to a textual model. You > might as well dumb everything down to an "object model." (see below) There exist dozens of proprietary database interfaces. Most people are willing to accept a common denominator which is mostly acceptable because the benefits gained by employing a widely accepted standard outweigh the benefits of a locally optimized proprietary interface. On the other hand if I want to create an optimized high performance system I already have lots of options. Most of these do use object oriented programming, not that I can't do it all in assembler, but rather because of the benefits of maintainability and the reasonable performance of modern compilers. The benefits of object oriented programming are orthogonal to object databases. > > If you buy this, then guess what the hype will be in three years: "These > new fangled data bases have this really cool feature, dude. You call it > with a SQL9X query and it can return like OBJECTS!. Everything in the > world can be expressed as objects! Lists of objects. Lists of objects. > Trees of objects. Directed graphs of objects. Arbitary graphs of objects. > It like unifies everything as objects. It's Zen, man. They call it 'JDBC' > and its totally wicked." What are you trying to say here? Are you criticizing objects? > > The *only benefit* of unifying things as DOMs is reusing software that was > originally supposed to work with XML (i.e. XSL implementations). If you > are writing new software it makes NO SENSE to do it through a DOM > interface unless your data source is *XML*. Suppose I want to process the data using XSL? Is this conceivably an acceptable reason to use a DOM interface (assuming I don't actually want to convert my database to serialized XML itself). > > Otherwise, you should just define a "tree node" interface and have your > various objects implement it. You will get all of the the benefits of the > DOM with none of the costs (i.e. how the hell do you represent complex > properties of objects???). If you want some good hints about what a "tree > node" interface looks like, take a look at the grove abstraction. > ... > > Second, Even *XSL* is not best served by a DOM representation. James Clark > wrote an xsl-list article about that but I can't find it now. Remember > that the DOM was invented as an extension of "DHTML." It's only half > "there." Certainly XSL is best served by a DOM representation if the data is presented via a DOM interface. The other option is to serialize everything. This makes no sense unless the DOM implemention is sub-optimal. > > But if I grant that some well-thought-through API for XSL trees could > exist (i.e. Jade's grove API) then I would propose that it only be used as > an optimization in a system where it would otherwise make sense to pass > around serializations of text documents. i.e. the DOM is okay for skipping > a layer of message passing. It is not okay as a "universal API" for "all > of the data in an organization." I never said this. There is a difference between saying that something is useful (i.e. placing a DOM interface on a database) and saying that this is the only way things ought to be done. > > To bastardize JWZ: "Sometimes people have a hard data unification problem. > One part of their organization speaks a very different language (at the > data model and object model level) than another part. They might think 'I > can unify these with XML or the DOM.' Now they have two problems." > > There second problem is that they didn't understand the really hard > problem in their organization. Data model unification is *easy* (cast to > java.lang.object or w3c.dom.node). Data model *rationalization* is very > difficult. And I don't think that there are many shortcuts. > > > Are the DOM interfaces the best for all situations, > clearly not. However if > > a significant percentage of people can agree to use them a significant > > percentage of the time, this is a big win. > > That's not going to happen. The DOM will NOT be a core tool for that > majority of OO programmers this year, next year, or ever. Programmers will > try it and increasingly find that if they are not doing XSL styling for > the Web or print that the DOM is not a core tool. "Old-fashioned" OO can > provide the same benefits. What I am saying is that if these interfaces are accepted as a standard mechanism for representing XML data, that this in and of itself is a big win. XML is not close to replacing OO in fact it seems to be struggling with OO concepts itself. It is a big mistake to assume that XSL is only to be used for 'styling for the Web or print'. DSSSL as we know is based upon or employs Scheme. Scheme is a full fledged programming language, a dialect of LISP. XSL does not have the Scheme counterpart to DSSSL, rather it is itself its own programming language (albeit currently simplistic). XSL is the first XML programming language and employs XML in a directly analagous way that LISP employs s-exprs. If I feel that I can express any data structure in XML that I can express as an s-expr, I see no good reason that, with proper extensions, XSL would not be able to handle tasks that Scheme, or Lisp have been applied toward. I believe XSL has a great future. If NN and IE contained native Lisp interpreters this might not be at all a big deal, what I find interesting is that a high percentage of desktops will, in the near future, gain the ability to run a data based transformation language. Perhaps the first use is an engine to display XML as HTML. I've developed a medical records system which employs XML and XSL to do relatively simple processing on the client (and have used the DOM interface for this BTW). As someone who has used many different programming languages and systems, I have found surprised at what can be done with the combination of XML, the DOM, XSL and JavaScript. The bottom line here is easy of development and deployment. This is my initial experience. Use your imagination. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
