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

Re: Addressing the Enterprise: Why the Web needs Groves

• From: Mike Champion <michael_champion@a...>
• To: xml-dev@i...
• Date: Sun, 06 Jun 1999 23:54:51 -0400

Paul Prescod wrote:

> The W3C has partially addressed this situation with a specification called
> the Document Object Model (DOM). Unfortunately the DOM is not really an
> object model in the abstract sense. It is rather just a collection of IDL
> interfaces and some descriptions of how they relate. This is different
> from an abstract object model because it is too flexible in some places
> and not flexible enough in others.

This was the subject of much discussion on the DOM interest group about
a year ago.  The resolution was that the InfoSet WG, not the DOM, has
responsibility for defining the "structure model" of XML (which I think
is the same as the "abstract object model").  When there is consensus on
what *the* abstract object model for XML is, the DOM will evolve to
reflect this consensus.


> 2.3 Defining views
> 
> The DOM has a more important inflexibility. It would be useful for the
> programmer using the DOM to be able to define whether all adjacent text
> nodes are merged or not. There is a "normalize" method that attempts to
> provide this feature that method actually modifies the tree. All viewers
> must see the same view. Another useful view is one in which every
> character is a separate node. That view allows us to address individual
> characters very easily. Another view might provide DTD information for a
> document. Yet another view would provide linking information. Still
> another view would attach RDF properties to the DOM.
> 

This seems like quite a useful idea.  Can anyone suggest an API for
this, 
perhaps Document::setView(int viewFlag)
where viewFlag is one of NORMALIZE, ONECHARPERNODE, etc.?  Or perhaps
the NodeIterators in the DOM Level 2 working draft could have factory
methods that 
make it easy to present such views?  (The latter is more in the spirit
of DOM Level 2, I personally believe).  Likewise, various Level 2
extensions are being considered to present a view of the text underneath
an element that eliminates the burden of navigating each TextNode
individually.  


> The W3C
> is working on a subset of XML to make XML easier to process for parsers
> but there is no such spec to make simpler DOMs for application writers.

FWIW, There is a strong sentiment among DOM people to defer working on a
simpler subset of the DOM until a simpler subset of XML is defined.

> The way we currently handle this is through different "levels" of the DOM.
> The second one is being worked on right now. These levels tend to lag
> behind the specifications that they are supposed to work with by months or
> years. There is a DOM for XML, HTML and CSS, but nothing for namespaces,
> RDF, XLink, XSL queries or XHTML. There is a single group within the W3C
> that will be responsible for building all of these "levels" of the DOM.
> This group of intelligent, well-meaning people is the most fundamental
> bottleneck in the standards world today.

<Blush> Well, that's gonna help me sleep at night! ;~)  

Seriously, I think this is an important misconception.  I believe I
speak for most people involved in the DOM in asserting that the RDF,
XLink, XHTML, etc. definers,implementers, and/or users can and should
develop DOM extensions of their own to avoid this very bottleneck. DOM
Level 2 will contain mechanisms to make it easier for independent groups
to develop APIs that provide convenient, powerful interfaces to the
semantics of specific XML applications that presumably are built upon or
in some way compatible with the DOM Core.  

For example, a "groves" API that extends the DOM to provide the features
Paul Prescod discusses could be defined by essentially anyone, submitted
to the W3C as Note, and the marketplace of ideas would determine the
extent to which it will be actually implemented and used.  Obviously the
DOM working group COULD tackle this job; the basic ideas of the groves
model were carefully considered and deliberately excluded from the DOM
API, mainly because most implementers balked at the
performance/footprint implications of many grove-related ideas.  So, go
ahead, somebody, prove us wrong! You don't need to convince anyone at
the W3C, just build a grove processing package that extends the DOM
interfaces, make it available to the world, then watch what happens.  I
guarantee you that there are plenty of people who would LOVE to see a
simple, usable, efficient object model for XML element text that avoids
the problems of TextNodes.  On the other hand, few of them are holding
their breath waiting ...

[If there are fundamental ways in which CORBA IDL or the DOM Core
inhibits such extensions, I'm sure we'd be interested in hearing the
details and would entertain suggestions of how to resolve such
limitations.]

Other matters under discussion here (especially the areas of XSL queries
and attaching metadata to documents via the DOM) may well be addressed
in DOM Level 3. This is a good time to start advocating specific
requirements or suggest APIs!

Mike Champion
Software AG 
and W3C DOM Working Group (speaking only for myself, etc.)

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

• Prev by Date: Re: Well-Formed SNAFU
• Next by Date: Re: Well-Formed SNAFU
• Previous by thread: Addressing the Enterprise: Why the Web needs Groves
• Next by thread: RDF and Resources
• Index(es):
  • Date
  • Thread