W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

RE: declarative expressons in WF2

From: T.V Raman <raman@google.com>
Date: Tue, 27 Mar 2007 09:28:50 -0700
Message-ID: <17929.17986.811365.63052@retriever.corp.google.com>
To: dsr@w3.org
Cc: raman@google.com, mikeschinkel@gmail.com, public-html@w3.org



Dave Raggett writes:
 > 
 > On Mon, 26 Mar 2007, T.V Raman wrote:
 > 
 > > Note that the XForms WG originally speculated on subsetting
 > > JavaScript, and for the reasons you mention decided to use XPath
 > > instead.
 > 
 > Hi Raman,
 > 
 > I am not sure what your point is in saying that.

It was mostly a "historical" note --- to ensure that the
background was not lost.

 > The only real
 > distinction is that XPath allows for the full set of XML
 > identifiers

Actually the real distinction is being side-effect free.

 > which is larger than for ECMA 262, and that XForms was aligning
 > itself with the suite of XML specifications including XML

The alignment with XML definitely made the XPath choice easier;
however I believe we would have chosen ECMAScript if it weren't
for the  problem of side-effects.

Another example of a W3C spec that debated long and hard about
subsetting ECMAScript was  the work on Semantic Interpretation in
the VBWG.

I tend to concurr with one of  the sentiments expressed earlier on
this thread;  subsetting an existing language usually ends up
inventing a new one.
 > Schema, XSLT, and XPath, so XPath was a clear winner over
 > ECMAScript.
 > 

Note that none of this is meant to take away from your goal of
enabling  the authoring of declarative constraints; I  think the
best way to motivate that is to  keep spread-sheets in mind, and
remember that we dont write a fresh program every time we file an
expense report.

 > But for non-techies who don't know programming languages, but do
 > know simple arithmetic expressions from their school days, there are
 > therefore different criteria in play.
 > 
 > As for the issues of calling external functions it doesn't matter
 > what expression language you use. Static analysis of
 > dependencies

You're correct; external functions -- be it XPath or JavaScript
-- are not any different from another when it comes to static analysis.
 > for function bodies is impractical. So you have to constrain such
 > functions. That is not a problem in practice, and if necessary you
 > can constrain the set of such functions to a predefined set.
 > 
 > p.s. authoring tools could reversably translate between XPath and a 
 > more user friendly format, so this isn't that big of a problem.
 > 
 >   Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Tuesday, 27 March 2007 16:29:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2007 16:29:48 GMT