Re: Question about bind element and its evaluation context

Hi Nick,

I would suggest that the "initial in-scope evaluation context" should be 
the node derived before evaluating the context attribute. 

The context attribute is evaluated based on the initial in-scope 
evaluation context.

The "in-scope evaluation context" of an element is the result of the 
context attribute, or the initial in-scope evaluation context if the 
context attribute is absent.

A bind element attaches MIPs to the nodes of a nodeset binding if the bind 
element specifies a nodeset binding, and otherwise the bind element 
attaches the MIPs to the initial in-scope evaluation context.

Best regards,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw






From:
Nick_Van_den_Bleeken@inventivegroup.com
To:
public-forms@w3.org
Date:
12/12/2008 05:15 AM
Subject:
Question about bind element and its evaluation context




All, 
I was trying to get some text for specifying to which nodes the MIPs of a 
bind are attached, but I ran into some trouble trying to do this. There 
are two different use cases we want to be able to support: 
<bind nodeset=”number” 
   type="card-number" required="../../type = ‘cc’" context="cc"/> 
In this first example we just want to attach the card-number type to the 
number element which is a child of cc. So we want to attach the MIPs to 
the nodes in the in-scope evaluation context, and  all XPath expressions 
in the MIPs will also use the same evaluation context. 


<bind nodeset=”number” 
     type="card-number" required="../../type = ‘cc’" context="cc"> 
  <bind constraint="isValidCC(owner, number, code)" context=".."/> 
</bind> 

In the second example we not only want to check if the credit card number 
is a valid credit card number, but we also want to check if the triple 
owner, card number and verification code is valid. To allow us to omit the 
‘../’ in the XPath expressions that select the nodes needed for the 
isValidCC() function we use the context attribute with "..".  The 
constraint MIP is still attached to number node, so in this case the MIPs 
are attached to the nodes in the initial evaluation context. 
On the Virtual day we decided to introduce a third evaluation context 
namely ‘amended in-scope evaluation context’.  But I have some trouble 
defining this context. My first shot was: 
amended in-scope evaluation context: The amended in-scope evaluation 
context  is equal to the in-scope evaluation context if a node-set-binding 
is specified on the bound element, otherwise it is equal to the initial 
evaluation context. 
This is a clean definition but isn’t correct because the context attribute 
itself is in the  node-set-binding attribute group. Due to the nature of 
making our spec modular we can’t list all attributes in the 
node-set-binding attribute group. And the only solution I see is the 
following definition: 
amended in-scope evaluation context: The amended in-scope evaluation 
context  is equal to the initial evaluation context if no node-set-binding 
attributes are specified other then the context attribute is specified. 
Otherwise the amended in-scope evaluation context  is equal to the 
in-scope evaluation context. 
I find it a bit of a hack to refer explicitly to the context attribute, it 
is added to the node-set-binding attributes in another module and there 
could be other modules that add attributes to the node-set-binding 
attributes which if they are treated special (like the context) make maybe 
more sense. Can anyone provide a 'cleaner' solution? 
Regards, 

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer 

-- 
This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
--