Re: [xml-dev] RE: Concerned about the increasing reliance on XPath

[Jim Melton <jim.melton@oracle.com>]

Apologies for this months-late reply, but I just realized that I'd 
never actually transmitted my first response, which was outdated by 
later responses on the thread.

Like both Greg and Dimitre have noted, it's not the syntax of the 
language that causes the perceived problem of complexity, but the 
semantics required by the problem being solved (overlooking the fact 
that the non-XML syntax of XPath requires a separate parser than the 
XML parser presumably being used to parse the XML document being 
validated...).  As Dimitre has observed, there is a perfectly 
reasonable (and standardized!) XML syntax for XPath; it's called 
XQueryX.  Of course, XQueryX can represent all of XQuery, but one can 
represent all of XQuery's subset, XPath, in XQueryX without using all 
of the XQuery language features not in XPath.

So what?  The only things you've gained are (1)the ability to avoid a 
separate parser for a different syntax and (2)the ability to do 
(relatively) easy programmatic manipulation of the syntax to modify 
expressions.  You haven't avoided any of the computational problems 
at all, and you've significantly decreased the readability of 
assertion expressions in XSD 1.1.  (In fact, because XML's open angle 
brackets can't be used in an attribute value expression, you'd have 
to use the character reference < throughout, and that would make 
things even more unreadable.)

For years on end, I've read complaints about how this language or 
that (e.g., SQL, XPath) is "too complex" and a "subset" is needed to 
make it feasible to implement.  Some (non-standardized) subsets have 
been invented and implemented, and then the complaints start to come 
about the loss of power ("if only the subset had just this one extra 
feature, it would solve my problem") or the increase in awkwardness 
("I can write an expression that does this, but it's completely 
unreadable and unmaintainable; if we added this syntactic sugar, the 
language would be so much easier to use").

There are undoubtedly cost-free, open-source, reasonable-license 
versions of XPath processors that can readily do what is required by 
any XML Schema validator, so somebody building a new XSD 1.1 
validator need not necessarily write a complete XPath processor from scratch.

Hope this helps,
   Jim


At 5/9/2011 06:26 PM, Greg Hunt wrote:
>Roger,
>I thought that your original point was that the calculation should be
>encoded as XML to make it easy to manipulate. The halting problem
>arises from the complexity of the behaviour that is described, not
>from its encoding.  You seem to want your hypothetical analysis to be
>capable of anything (you did not seriously limit its scope in your
>example), in which case ecoding the instructions as XML doesn't get
>you much if anything over encoding them in some programming language
>(modulo the parsing required).
>
>Analysis becomes difficult when the behaviour that is described
>becomes sufficiently complex (for suitable values of "difficult" and
>"complex").  Your initial example seemed to suggest that you want to
>constrain the set of behaviours that the XPath could have.    If the
>same things are encoded as XPath or as some bespoke XML then the
>analysis of behaviour (after parsing) has the same degree of
>complexity because they are instructions for the same behaviours.
>Thats just a matter of defining a subset of the full language and
>enforcing that subset (I've seen examples of that).  Of course, if you
>have very few behaviours that you want to support (sum for example)
>then your XML element approach is easiest to implement, but as the
>number grows and the complexity of the operations grows the argument
>for picking up someone else's XPath implementation becomes stronger
>(for example avoiding mixing data and instructions, avoiding writing
>the code to implement the operations).
>
>Greg
>
>On Tue, May 10, 2011 at 6:20 AM, Costello, Roger L. 
><costello@mitre.org> wrote:
> > Hi Dimitre,
> >
> >> 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.
> >
> > You stated the problem perfectly:
> >
> >   ... analyzing/assessing programs is equivalent
> >   to the halting problem
> >
> > That is, once XPath is introduced into an XML vocabulary then 
> analysis/assessment becomes impossible.
> >
> > Often it is not necessary to express *any* possible relationship. 
> For my "purchase XML vocabulary" it seems reasonable that one 
> should be able to identify the relationships that are really 
> needed. It is unlikely that *any* relationship is needed.
> >
> > By constraining the set of relationships -- using XML markup -- 
> then the analysis/assessment problem is reduced from the halting 
> problem (i.e., impossible) to something that is achievable.
> >
> > /Roger
> >
> > -----Original Message-----
> > From: Dimitre Novatchev [mailto:dnovatchev@gmail.com]
> > Sent: Monday, May 09, 2011 4:05 PM
> > To: Costello, Roger L.
> > Cc: xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] 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
> >>
> >>
> >
>
>_______________________________________________________________________
>
>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

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Chair, ISO/IEC JTC1/SC32 and W3C XML Query WG    Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Alternate email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA  Personal email: SheltieJim at xmission dot com
========================================================================
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================