Re: Model driven switch

Hi Nick,

Thanks for the fast turnaround on your review.

For *, I added a clarifying sentence to say that the data value is not 
changed when a case is selected whose ID does not match the value in the 
node indicated by caseref.  The important issue is that a data value in 
the model consistently causes the selection of the same case across 
implementations.  It is not necessary to introduce a side-effect value 
change as an implicit part of caseref processing in order to achieve this 
effect.

For **, xforms-value-changed is an event associated with Single Node 
Bindings, which caseref isn't.  There's no text to suggest an 
xforms-value-changed, so one doesn't happen.  However, for other events, I 
think specifically xforms-select and xforms-deselect occur normally 
whether the cases are switched by a caseref value change or by a toggle. I 
found the description of the case element to be somewhat lacking in that 
it does not say this, even though the description of the 
xforms-select/xforms-deselect events do indicate the case element as a 
target.  In previous versions of the XForms spec, we have been asked to 
infer that the events occur, so I some text to explicitly state that it 
occurs.  The text indicates that case element switching produces the 
events and does not indicate that the events only occur if you change the 
cases in a particular way.

For ***, the caseref is not affected by non-relevance because it doesn't 
say that it does.  Numerous other xpaths are able to refer to and use 
non-relevant nodes, such as performing a calculation.  When performing a 
calculation, we don't say that non-relevant nodes are dropped from a 
calculation, and because we don't say it, then they aren't.  As a separate 
issue, the non-existence of the node indicated the caseref expression is 
explicitly handled in the text already.  It corresponds to empty string 
when setting the switch case, and a value is only stored if the node 
exists when attempting to switch the case.  A switch is still expected to 
keep track of what case it is on during run-time even if the caseref does 
not indicate a node, but there's nothing in the text to suggest otherwise. 
 It's the same as if the caseref attribute were omitted.  I did add a 
clarifying content to the first paragraph of the case element text that 
happens to also clarify this point. 

Also, for *** I do agree that an adjustment is needed in section 4.9 of 
the xpath module [1], which indicate that "implicit" instance nodes are 
created for the case() function and index() function.  However, I think 
this change will take the form of a note that indicates implementers will 
have the option of using the explicit nodes indicated by caseref and 
indexref, if they exist, but then they will have to deal with what happens 
if the caseref and indexref change between indicating a node and not 
indicating a node, and vice versa.  Equally an implementation could create 
the implicit nodes to drive case() and index() and treat that as totally 
unrelated to the behavior of the caseref attribute and the indexref 
attribute.

[1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/xpath20/index-all.html#additional-references

Finally, note that I've now adjusted the toggle action to reflect the 
changes needed for caseref, and I've added the caseref example to the 
switch section.

Thanks,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
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 <Nick.Van.den.Bleeken@inventivegroup.com>
To:     Public Forms <public-forms@w3.org>
Cc:     John Boyer/CanWest/IBM@IBMCA
Date:   08/30/2011 07:28 AM
Subject:        Model driven switch



Hi John, 

The tekst looks good, I have a couple questions/remarks about border cases 
though ;)

* What happens when the string value of the caseref doesn't matches a case 
(initially or after an set value), the spec says that the first case is 
then selected, but is the value in the model then also updated 
accordingly?
** Are there any forms-value-change events targeted to the switch if the 
caseref value changes (and other events) I don't think this will be the 
case.
** What if the node the caseref  points to isn't relevant or doesn't 
exists, how does the model driven switch keeps track of its state (I would 
have expected that when using the caseref attribute, the node it points to 
replaces the implicit node used by ui driven switch)



Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com
www.inventivedesigners.com






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