Lists Home |
Date Index |
- From: "Borden, Jonathan" <email@example.com>
- To: "Paul Prescod" <firstname.lastname@example.org>, "XML Developers' List" <email@example.com>
- Date: Wed, 3 Feb 1999 00:33:51 -0500
Paul Prescod wrote:
> You certainly would if you use XML as *only* a serialization. The thrust
> of this thread was that some people want to encode everything in XML so
> that they can "query it." But XML is a lousy query representation for
> anything other than human-authored documents. (and debatably the best
> thing for queries against those!)
> I think that this is Eliot's point. Consider someone who says that if you
> put a "DOM interface" on all objects everywhere in the system then they
> all become managable because they have a "single API." Smart (but usually
> inexperienced) people say this. These people are talking about an API to
> the serialization structure instead of an API to their original data.
> They've gained some uniformity but lost some abstraction. That is very
> seldom a useful trade-off. To make their processing useful again their
> very next step will be to add in some abstraction on top of the DOM. Then
> they're back to where they started.
> This is one of the most pervasive misunderstandings in XML-world.
You have missed the point here. If I put a DOM interface onto a SQL Server
or Oracle or ODI or Poet database, I am hardly using an API to the
serialization structure. When people say this, they mean that the DOM
API/interface is used against the native datastore. The utility of this
would demonstrate itself in a distributed environment where something like
XQL was used as a query language. If we are in the relational db world,
ODBC/SQL 92 provides an interface onto disparate databases. Not all
information is stored on relational dbs. The DOM interface aims to provide
the same database and vendor neutrality and interoperability that ODBC or
JDBC provides for tabular data. 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.
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.
XSL transforms can be applied directly to DOM representations, rather than
serialized XML documents. This yeilds the possibility that serial transforms
be applied within 'DOM space' (assuming the XSL transform output is a DOM
structure rather than a serialized string). The act, thus, of web page
generation from a database can be automated via XSL rather than, say ASP or
perl scripts. Is this useful? Sometimes it is.
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.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)