XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The limitations of XPath and navigation for XML databaseprocessing

Michael David writes:

> My definition of procedural and nonprocedural  (or 
> declarative), which I still go by, is that procedural languages
> require the user to specify what data is needed and how to get 
> it, while nonprocedural languages require a user to specifying 
> what data is needed without specifying how to get it. 

Yes, but I think you're misreading XPath.   By that definition, it's 
declarative, though that may not be obvious.   Let's look at a simple 
XPath:

/A/B/C

Someone could have specified the languages as: "First you go to the root, 
then you find an A, then within that you find a B".  That's a procedural 
language, and it's probably how you're thinking about it.  That's not the 
way I look at XPath and I think not the way it's intended to be looked at. 
 I believe that the intended way to think about the same expression is: 
"This expression matches any one or more C's that are within B's that are 
within an A that's an immediate child of the root.

Note that this latter interpretation does >not< tell you how to find them. 
 One obvious way, is to find all the A's, then within that find all the 
Bs, and so on, but there are other implementation strategies.  You might 
read in a whole document, make a hash to find out where all the elements 
are by name, and by the way count the number of occurrences and set up 
parent pointers.  You might notice that while there are 100,000 As, there 
are only 2 Cs.  Using this information, an XPath optimizer might decide to 
go directly to each of the Cs and follow its parent chain to discover 
whether it in fact satisfies the XPath.

I think it's fair to say that this is exactly the sort of optimization 
that's done with SQL.  I believe it's also in the spirit of what's done by 
many optimized XQuery implementations.  I agree with Michael Kay;  XPath 
is declarative in very much the same sense that SQL is.  It does not 
prescribe steps you must take in order -- it specifies declaratively what 
you must find.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS