Re: [xml-dev] Formulas in XML values

[COUTHURES Alain <alain.couthures@agencexml.com>]

Kurt,

Thank you very much for your answer.

In fact, I'm more concerned with validation than evaluation. My point of 
view is that 25+17 should be considered as a valid integer because it's 
just an unusual notation for 42 !

So, I enter "25+17" in an XForms input field of "xsd:int" type, it's 
valid and associated constraints are tested with the value 42 and 
depending fields, such as sums, are updated as if I entered "42" instead.

It's a deep-level idea ! I wouldn't consider this with a relational 
database because, there, integers are stored in binary format. XML can 
be smarter because it's a text notation.

With just numbers and operators, Javascript eval() is good enough for 
XSLTForms. With functions and constants, it might be more complicated 
but regular expressions might help for a Javascript evaluation or, as 
you suggested, XSLT. XPath notation might be recommended.

I'm not now specially concerned about performance because these should 
be very simple expressions (it's always possible to check that there is 
no operator before starting to evaluate...).

Wouldn't it be great if "1/3 + 2/3" was exactly like "1" ? As I said, 
computers should be as smart as students calculators !! This should be 
performed at low-level (even if XSLT wouldn't so bad for such analysis...).

Even if it sounds simple, this should be a big evolution !

Alain Couthures
<agenceXML>
http://www.agencexml.com

Kurt Cagle a écrit :
> Alain,
>
> This is an interesting point, and a subtle one (and that it comes up 
> in XBRL surprises me not in the least). If I understand it correctly, 
> what you're asking is, if you have an XML expression of the form:
>
> <account-total value="29 + 12 * 1.25"/>
>
> how you can effectively evaluate this statement via XPath. The 
> expression in the value attribute is essentially an anonymous function -
>
> <account-total value="fn(){29 + 12 * 1.25}"/>
>
> In the current implementation of XPath, there is no mechanism to 
> enable the evaluation of anonymous functions, because that's a second 
> order operation. There is some discussion in the XQuery 1.1 spec about 
> working with higher functions, I'd have to dig into it a bit in order 
> to tell you precisely where, however. This gets more complicated of 
> course because there is nothing in the current data model for dealing 
> with a function as a data type (the only way you could schematically 
> define the above @value attribute is as xs:string, even though, as a 
> numeric function, it should properly be defined as of type xs:double).
>
> In practice, of course, you can always create an eval type function, 
> though given XSLTForm's architecture, that could prove to be exciting 
> (I'm guessing you'd have to run the expression through an XSLT again 
> in order to properly evaluate it, assuming that you're just dealing 
> with constants).
>
> Kurt Cagle
> Managing Editor
> http://xmlToday.org
>