[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Concerned about the increasing reliance on XPath
- From: "David Lee" <dlee@calldei.com>
- To: "'Costello, Roger L.'" <costello@mitre.org>, <xml-dev@lists.xml.org>
- Date: Sat, 7 May 2011 11:32:22 -0400
" If I write an application that will process an XML vocabulary and that can
contain XPath then my application must implement the entire XPath
specification"
Only if you use an application environment that doesn't already include
xpath.
I assert that a large (and growing) set of language environments *already
include* xpath so you dont have to implement them yourself.
But yes if your using an environment where you dont have access to XPath
then you'll have to write it yourself, and that is daunting.
Similarly to say languages that have no support for String object or
support for loops or arrays or javascript or <insert feature X>
Or more to the point what if your language doesn't have an XML parser ? does
that make reliance on XML "bad" ?
This is a similar situation every 'generation' of languages/toolkits. At
first new technologies are not omnipresent so you have to write them
yourself.
Eventually the winners become omnipresent.
Summarize: I suggest your question really is about language and toolkit
environments and whats included already, not about XPath itself.
----------------------------------------
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 11:12 AM
To: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Concerned about the increasing reliance on XPath
Hi David,
> But do you have support to your assertion that xpath requires large
> computation for simple expressions ?
If I write an application that will process an XML vocabulary and that can
contain XPath then my application must implement the entire XPath
specification. Michael Kay's book on XPath 2.0 is 552 pages [1]. That's a
lot of stuff for my application to implement.
Are you making a distinction when you say "xpath ... for simple
expressions"? Note that, for example, the new XML Schema assert element
(mostly) permits the entire XPath language. It does not restrict it to a
"simple expressions" subset.
/Roger
[1]
http://www.amazon.com/XPath-2-0-Programmers-Reference-Programmer/dp/07645691
04/ref=sr_1_3?ie=UTF8&qid=1304780709&sr=8-3
-----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: [xml-dev] 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: [xml-dev] 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]