XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: Concerned about the increasing reliance on XPath

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS