[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: Stephen D Green <stephengreenubl@gmail.com>
• To: "Costello, Roger L." <costello@mitre.org>, XML Developers List <xml-dev@l...>
• Date: Mon, 9 May 2011 21:31:37 +0100

sorry the (view) output should have been
  <Purchase>
      <Item>10.00</Item>
      <Item>20.00</Item>
      <Total>
            <SumPrecedingItems>
                 <Value>30.00</Value>
            </SumPrecedingItems>
      </Total>
  </Purchase>
----
Stephen D Green



On 9 May 2011 21:29, Stephen D Green <stephengreenubl@gmail.com> wrote:
> How about separating the logic from the model
>
> The model would be
>  <Purchase>
>      <Item>10.00</Item>
>      <Item>20.00</Item>
>      <Total>
>            <SumPrecedingItems>
>                 <Value></Value>
>            </SumPrecedingItems>
>      </Total>
>  </Purchase>
>
> Like with XForms you could add to this model in another
> construct somewhere a binding between the Value element
> and the sum() XPath. Another binding would associate the
> Value element with the decimal type. Validation could be
> inbuilt too, perhaps using a schema for the model. Then
> the view is produced at runtime by evaluating the XPath,
> putting the result in the Value element, validating its type
> and, if all is well, outputting the result as
>
>  <Purchase>
>      <Item>10.00</Item>
>      <Item>20.00</Item>
>      <Total>
>            <SumPrecedingItems>
>                 <Value></Value>
>            </SumPrecedingItems>
>      </Total>
>  </Purchase>
>
> or some graphical formatted rendering of it. Needn't use
> XForms but the MVC design is normal stuff. Just add code.
> And just need to separate model view and controller and
> not put the XPath in the model, put it in the controller. I
> guess maybe the point is that XML Schema 1.1 might be
> mixing model and controller, is it?
>
> ----
> Stephen D Green
>
>
>
> On 9 May 2011 20:18, 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
>>
>>
>

• References:
  • Concerned about the increasing reliance on XPath
    • From: "Costello, Roger L." <costello@mitre.org>
  • RE: Concerned about the increasing reliance on XPath
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: RE: Concerned about the increasing reliance on XPath
    • From: Stephen D Green <stephengreenubl@gmail.com>