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 database processing

-----Original Message-----
From: Xia Li [mailto:xli@galdosinc.com]
Sent: Thursday, February 7, 2008 08:14 PM
To: mike@adatinc.com, noah_mendelsohn@us.ibm.com
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] The limitations of XPath and navigation for XML database processing

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

Hi Mike,


You wrote, ?What it boils down to with me is that XPath is logically specifying the logic (externally) that is needed to be performed (internally). The external navigation instructions must be specified procedurally to correctly define any of the possible choices for internal operations.?


But it is not XPath requires you to define the detailed step from A to C with /A/B/C. It is the requirement of your application that requires you to give such a detailed step so that you can get the C that appears within B which is under A. If your application, for example, just want to retrieve C no matter where it appears, then even with XPath, you can just say ?//C? without giving every step from A to C. So I think the path is actually says what you want instead of instructing the processor how to get it.  




Hi Lisa,


What about ?//C//G?.  To me as an external user, it says go to C, then go to G (from C). How it is processed internally is not important as long as it gets the right result.  "//C" could be argued either way I think, but generally navigation has to be externally specified as a series of steps.



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