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

APIs ... Re: CDATA by any other name... (was The raw and the cooked)

  • From: Paul Prescod <papresco@t...>
  • To: XML Dev <xml-dev@i...>
  • Date: Sat, 07 Nov 1998 19:33:24 -0600

xml cdata database data
David Brownell wrote:
> > I find it odd that we can have "standard APIs" for the full complexity of
> > relational data, and probably eventually for object database data, but it
> > is perceived to be impossible to do the same for the parse tree of XML
> > data. I mean it is just annotated tree structures: it shouldn't be rocket
> > science (but neither is it trivial).
> If it's just annotated tree structures, I'd say that's what DOM is for!
> Or should be, warts and XML Data Model conformance aside.

That's right. If the DOM were done right, it would be what I would call a
"standard API" for XML data. It wouldn't be appropriate for the the 
abstract, arbitrarily complex data models built on top of XML. It would
be for the XML data itself. But the DOM is quite far from that. It is
geared towards scripters and is thus not general enough for the problems
I would like to solve.

> Why would I say no "standard API" would exist for the rest?  There are
> thousands (conservatively!) of data/object models specialized to each
> application.  While a tree (or grove, or graph) would seem isomorphic
> with any such model, it's not necessarily optimal for any one of them.

That's true. Similarly, a relational data model is not the only API in
every application that *uses* a relational model, but you could say that a
single relational database API (ODBC) is usually sufficient. That's all I
would hope to replicate.

> Similarly, "pure data" is a model many of us have been moving folk away
> from over the last decade.  It's critical for interoperability between
> system components (e.g. over the web, with XML!), but raw data must be
> joined with methods (or other code) before it's used.  Ergo, "objects"
> instead of APIs to data; classes not structs.

Yes, there is an impedence mismatch that must be overcome between the XML
data model and your application's data model, just as there is a mismatch
between OO programs and relational data. A standard XML-level API (or
two, one event driven and one tree driven) would help us to overcome that, 
not perpetuate it.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?

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/
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...)


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.
First Name
Last Name
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.