[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Concerned about the increasing reliance on XPath

  • From: Dimitre Novatchev <dnovatchev@gmail.com>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Mon, 9 May 2011 13:05:15 -0700

Re:  RE: Concerned about the increasing reliance on XPath
> Assessing the <Item> elements is easy; they just contain decimal values. Assessing the <Total> element is probably impossible since it can contain any arbitrary XPath expression.
>
> That's bad.
>
> XPath is fine if all you want to do is "execute" the XML vocabulary. But if you want to "assess/analyze" your  XML vocabulary then XPath is not fine.


This is true for any programming language. Why should the use of XPath
be any different? If you need to express *any* possible relationships
then most probably you need a full-fledged programming language and
analyzing/assessing programs is equivalent to the halting problem.


Please, reformulate, or otherwise this strikes the reader as another
rediscovering the wheel.

-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.


On Mon, May 9, 2011 at 12:18 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> Suppose you create an XML vocabulary for describing purchases:
>
> Purchase
>     Item: decimal
>     Total: XPath
>
> The value of <Total> is any XPath expression.
>
> Here's a sample instance document:
>
> <Purchase>
>      <Item>10.00</Item>
>      <Item>20.00</Item>
>      <Total>sum(../Item)</Total>
> </Purchase>
>
> You input that instance document into your "purchase processor" and it outputs:
>
>    Your purchases:
>        Item: $10.00
>        Item: $20.00
>        Total: $30.00
>
> The XPath expression in the <Total> element was evaluated by the "purchase processor."
>
> The <Total> element is powerful - the full power of XPath is available to it. To further illustrate its power, we could write an XPath expression to convert the sum of the Items to another currency:
>
>    <Total>sum(../Item) * 2.1034</Total>
>
> Or we could write an XPath expression that pulls in data from other documents to compute the total.
>
> Pretty powerful, aye?
>
> Now, write this tool: the input to the tool is a "purchase instance document", such as this:
>
> <Purchase>
>      <Item>10.00</Item>
>      <Item>20.00</Item>
>      <Total>sum(../Item)</Total>
> </Purchase>
>
> The tool assesses the instance document and outputs the results of the assessment.
>
> Ouch!
>
> Assessing the <Item> elements is easy; they just contain decimal values. Assessing the <Total> element is probably impossible since it can contain any arbitrary XPath expression.
>
> That's bad.
>
> XPath is fine if all you want to do is "execute" the XML vocabulary. But if you want to "assess/analyze" your  XML vocabulary then XPath is not fine.
>
> Contrast the above with this XML vocabulary:
>
> Purchase
>     Item: decimal
>     Total
>         SumPrecedingItems
>              Value: decimal
>
> Here's a sample instance document:
>
> <Purchase>
>      <Item>10.00</Item>
>      <Item>20.00</Item>
>      <Total>
>            <SumPrecedingItems>
>                 <Value>30.00</Value>
>            </SumPrecedingItems>
>      </Total>
> </Purchase>
>
> The <Total> element is much less powerful - its content is an element that has the semantics "sum all the preceding <Item> elements."
>
> Now, write a tool in which you give it a "purchase instance document" and it assesses the instance document.
>
> Easy!
>
> Analysis of the XML vocabulary is possible (easy, in fact).
>
> Summary: if an XML vocabulary permits XPath expressions then analysis of the XML vocabulary becomes exceedingly difficult (or impossible).
>
> Comments?
>
> /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
>
>


[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.