Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Concerned about the increasing reliance on XPath
 As a counter-contra-point I was of this same opinion in 2000 when I first had to implement XML interfaces to a 4GL language ( Centura Desktop Developer anyone ? no ?) My 'intuitive' feeling was that XPath was an unnecessary overhead. I have since been 'converted'. My current opinion is that with modern implementations, the major area that XPath suffers is that it requires loading the entire document into memory to support the entire syntax. Its true that some work has been done with 'streamable xpath' that can avoid this is some cases, but in general, the high level XML tools in general (XPath, XQuery, XSLT etc) are based on an in-memory representation. (ignoring XML Databases for the moment). This can be a problem ... but the solution rarely is avoiding xpath, and xpath IMHO isnt the bottlneck. You'll see similar performance writing your own code against an in-memory tree. If you really have a need to avoid loading the document into memory you need to resort to streaming API's. Its not the xpath thats the performance issue in these cases, its the loading-xml-into-memory that is. Fortunately there is some awesome work going on to support streamable subsets into XPath, XSLT and XQuery ... So to conclude, I would argue that reliance on xpath is not a bad thing at all, its very good. If you didn't have XPath you probably couldn't implement your "simpler" solution any more efficiently, and would loose in flexibility. Side note <insert plug> using Streaming API's doesn't always mean you have to jump down a level of language. In addition to the example given above (streamable subsets of Xpath/XQuery/XSLT ) referenced above, xmlsh exposes a very high level scriptable streaming API which I've used in production to process huge amounts of XML (GB's) that wouldnt fit into memory nearly as efficiently as a pure java implementation. However the types of things you can do with this API are limited to a narrow scope, mainly looking at the current node, and skipping ahead to the next matching node. Note this is still somewhat experimental and not fully documented yet but you can get the idea here http://www.xmlsh.org/FunctionsStAX A simple example being http://www.xmlsh.org/FunctionStAXgetData http://www.xmlsh.org/FunctionStAXgetAttribute <end plug> But again, this really only gives a significant performance gain when dealing with large documents and very simple operations. ---------------------------------------- David A. Lee dlee@calldei.com http://www.xmlsh.org -----Original Message----- From: David Lee [mailto:dlee@calldei.com] Sent: Saturday, May 07, 2011 10:59 AM To: 'Costello, Roger L.'; xml-dev@lists.xml.org Subject: RE: Concerned about the increasing reliance on XPath Contra-point. Do you have any tangible evidence that using XPath with simple expressions requires significant processing ? Its true that it requires the support infrastructure - and the same can be said of any level of computation that requires a lower layer (which is prety much all ). But do you have support to your assentation that xpath requires large computation for simple expressions ? ---------------------------------------- David A. Lee dlee@calldei.com http://www.xmlsh.org -----Original Message----- From: Costello, Roger L. [mailto:costello@mitre.org] Sent: Saturday, May 07, 2011 9:52 AM To: xml-dev@lists.xml.org Subject: Concerned about the increasing reliance on XPath Hi Folks, XPath is a fabulous language. It is incredibly powerful. It is a large, rich language. I have observed in increasing usage of XPath. For example, in XML Schema 1.1 the new assert element uses XPath to express constraints: <assert test="XPath" /> XPath gives a lot of power to the assert element. But it also means that a lot of power is needed to evaluate the assert element. To evaluate that tiny, innocuous assert element you need to implement the entire XPath language. Suppose the assert element was simplified. The only kind of assertion that can be made is, "The value of the first child element must be greater than the value of the second child element." Here's how we might use it to express the constraint between a meeting's start time and end time: <greaterThan> <element name="start-time" type="dateTime" /> <element name="end-time" type="dateTime" /> </greaterThan> Very little power is needed to evaluate this "assertion". The assertion is expressed entirely in XML markup. We've lost an enormous amount of power/expressivity. But we've gained in reduced cost of evaluation/processing/coding. While XPath is nice, it is: - not XML - requires huge amounts of processing (i.e., coding) wherever it's used I am concerned about the increasing reliance on XPath. My Position: In some cases it would be better to ratchet down capabilities and use XML markup rather than XPath. I know many people will disagree with my position. Let's have a good discussion of the issue. Here's the issue: Issue: Is the increasing reliance on XPath a positive or negative trend? (Implicit in this "issue" is an assumption that there is indeed a growing trend toward using XPath) /Roger _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
