OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Xpath and DOM

[ Lists Home | Date Index | Thread Index ]
  • From: uche.ogbuji@fourthought.com
  • To: "David Orchard" <orchard@pacificspirit.com>
  • Date: Sun, 26 Dec 1999 14:03:25 -0700

[Cross-posted to xml-dev@ic.ac.uk and www-dom@w3.org]

> Leigh, I completely agree with you.  I have been in some discussions about
> this already so I'll try to relay what I've heard.
> 
> About 6 weeks ago, I asked Lauren Wood about DOM implementing XPath.  My
> version of her answer is "Nobody asked for it for Level 2 or Level 3, and
> Level 2 is too late now.  Nobody volunteered to write it for the DOM Spec".
> There's no technical reason why getElementByXPathExpr couldn't be added.
> 
> I asked some of the other IBM XML standards reps about this and my version
> of their answer is "XPath is a query language, and we've got a better query
> language coming.  Why support an inferior query language now when we'll have
> to support the better one soon.  Additionally, why should the DOM be the
> bucket for all API gorp?  Query should be built on top of the DOM so we can
> have layered parsers".
> 
> On one hand, I want an interoperable getElementByXPathExpr, but I understand
> the political and technical reasons why the DOM group isn't rushing to
> implement it.

Am I entirely missing something?  Why are there all these proposals for adding 
the trappings of separate recommendations into the core DOM?  Namespaces make 
sense because they are a fundamental part od XML, and will probably be 
incorporated into the XML 2.0 spec, but why should DOM define a 
getElementByXPathExpr or the like?  I would see this to be the task of the 
XPath spec to define an interface for XPath processing given a DOM.

For instance, we just added an "Evaluate" function to 4XPath, which takes an 
XPath string and a DOM Node (for context) and returns a NodeList.  4DOM users 
don't have to worry about all the machinery of XPath, but 4XPath users, who 
already need 4DOM anyway, now have XPath query support in addition.  It would 
be nice to have a standard interface for this, but I don't think DOM level N 
is the place for it.

And if it is, how do you choose which specs get grafted into the DOM?  Is it 
only W3C specs?  If not, what are the criteria?

IMHO, The DOM should be a simple, low-level interface for XML and no more.  
Other specs should refer to the DOM, but not vice-versa.

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS