Re: repeats

Hi Jason,

Previously, I had decided not to persist discussing your repeat thread 
when you decided to substitute being rude for being right.
However, it appears that the thread has shifted even if the subject line 
has not.

I would recommend reading the mail archive since the discussion of a 
bind() function is years old.
As I said, I *would* recommend it, except that the Forms WG has been 
members only for some reason beyond my comprehension; we have recently 
simply started to hold the discussions on the public list, and the 
recharter makes us a public (not members only) working group.

As with my prior emails to you, let me reiterate the caution that language 
design is a challenging job because you can't just throw in features for 
the immediate eye candy that they provide without also considering how the 
feature affects the rest of the language.  XPaths are used throughout 
XForms.  The bind() function is in the function library available to 
XPaths.  So, what is the expected behavior of the bind() function in *all* 
XPaths?

Here are some more focused questions.

1) What if bind() appears in the nodeset attribute of a bind?

2) What if bind() appears in a model item property expression?

3) What if bind() appears in an XPath-based attribute of submission, but 
it refers to a nodeset in another model?

4) What if bind() is invoked more than once in the same XPath, but it does 
not refer to nodes in the same model as the initial context node (the one 
returned by current())?

5) Presumably bind() will take a string parameter with an IDREF value. 
Factor all of the above questions by the question of what happens if a 
non-literal value is used for the parameter.  Factor again by what is 
supposed to happen if a bind function is used to help determine the 
parameter to the bind function.

The answers to questions 1 and 5 are that the proper order in which to 
read bind elements during a rebuild becomes non-deterministic.  Not 
exactly the harbinger of interoperability. The answer to question #2 is 
not much better (and possibly just as bad).  And frankly, only recently 
have I gotten to writing the new material for the horribly bad Section 7.4 
that would allow reasonable answers to #3 and #4.

Anyway, all that being said, I *really* hate the bind attribute as much as 
you do.  And frankly, I wouldn't have responded to this email either just 
to provide admonishment about why it is not so simple...

Instead, recently I've been tasked with applying an erratum to the claim 
that failures of XPath functions must result in an 
xforms-compute-exception.  Since the functions can also be invoked in 
XPaths that are not in MIP attributes, issuing an xforms-compute-exception 
is not correct, so the group wants an xforms-binding-exception instead 
(when the XPath is not in a MIP attribute, of course).

Well, now that the group is clear that XPath functions can make this 
decision, it seems reasonable to discuss the possibility of XPath 
functions making other similar decisions based on where they are located 
in the document.  Specifically, we seem to *really* be in need of a bind() 
function for UI binding expressions but not model binding expressions.  I 
think it would be a lot easier to say that the function causes an 
exception when invoked from a model binding expression.  It can also cause 
an exception if it requests  a bind "from a model other than the one 
associated with the in-scope evaluation context node used to start 
evaluatoin of the containing XPath expression."

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Jason <jeacott@hardlight.com.au> 
Sent by: www-forms-request@w3.org
11/13/2006 02:51 PM
Please respond to
jeacott@hardlight.com.au


To
mark.birbeck@x-port.net
cc
Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org
Subject
Re: repeats







 >.. a globally useful bind function would be a far better solution than 
 >doubling up on attribute names.

Or perhaps a ref/xpath function instead? binds could be the default, and 
a ref function would encourage the use of binds without any increase in 
function calls.

Jason.