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

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

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

David Brownell wrote:
> 
> To put it differently:  is there really room for another API
> to represent XML structure?
> 
> I tend to think that DOM, warts and all, is "good enough" for
> most purposes.  And for those other purposes, I suspect that
> no standard API could suit.

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

No, we don't have such a thing yet, because it is not easy to develop and
nobody is willing to stop and think things through. Over time,
organizations like TechnoTeacher and ISOGEN *are* thinking it through. I
don't claim we've got the problem solved, but our direction is already
much more scalable, generalized and rigorous than what we are seeing in
the DOM realm.

Our approach is, we think, the same as the one taken by the relational
database people: first think of a model that supports the range of
applications that we want to support (including editing applications,
repositories, simple read-only processors) and data types that we want to
support (documents, DTDs, schemas, "link maps", vector and bitmap
graphics,... all media). Having defined the model, we need a way to
customize it for a particular application: a schema, just as they have
schemas in the relational and object database worlds. Our schemas are
property sets (the schema language needs to be stronger, if it is to
support read-write applications...we know that part needs work).

Then we develop an API to encapsulate the model. We are working on that
API right now.

Anyone who wants to follow our thinking can start with the tutorial on
groves at http://www.prescod.net/groves/shorttut As you can see from the
tutorial, the model is simpler than the relational model and yet seems
more or less complete (I know of one suggestion for enhancement). As I
said before, the schema language and the APIs are the parts that must
change now.

If there is a reason that this generalized approach *must* fail and cannot
be the basis of a variety of applications, then I would like to hear about
it sooner than later, so I invite comments from skeptics.

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

"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin

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

• Follow-Ups:
  • Re: CDATA by any other name... (was The raw and the cooked)
    • From: David Brownell <db@E...>
  • Standard XML APIs (was Re: CDATA by any other name...)
    • From: <david@m...>

• References:
  • RE: CDATA by any other name... (was The raw and the cooked)
    • From: "Lauren Wood" <lauren@s...>
  • Re: CDATA by any other name... (was The raw and the cooked)
    • From: Paul Prescod <papresco@t...>
  • Re: CDATA by any other name... (was The raw and the cooked)
    • From: John Cowan <cowan@l...>
  • Re: CDATA by any other name... (was The raw and the cooked)
    • From: David Brownell <db@E...>

• Prev by Date: XML in IE5 beta PR2
• Next by Date: RE: Retrieving attributes from an internal entity
• Previous by thread: Re: CDATA by any other name... (was The raw and the cooked)
• Next by thread: Standard XML APIs (was Re: CDATA by any other name...)
• Index(es):
  • Date
  • Thread