Same model item property on the same node

Combining MIPs of a given type on a same node

We relax the constraint that only one MIP can apply to a given node. Depending on the MIP:

type	combinator
type	AND
constraint	AND
required	OR
readonly	OR
relevant	AND
calculate	disallow
p3ptype	disallow

For reference, XForms 1.1 says:

• "6.1 Model Item Property Definitions": "It is an error to attempt to set a model item property twice on the same node (see 4.3.1 The xforms-rebuild Event for details)." -> remove that sentence and put table/explanation on how MIPs combine here.
• "4.3.1 The xforms-rebuild Event": "If a node already contains a model item property of the same name due to the processing of prior bind elements, then XForms processing for the containing document halts with an exception (4.5.1 The xforms-binding-exception Event)." -> change part after "then the results are combined as described in section 6.1".

The two sections above will have to be changed.

Historical

NOTE: For XForms 2.0, the combinator is predefined.

From John:

Hi Nick,

I thought we had discussed a syntax that was better than the original 
proposal, namely that each possible MIP could possibly be expressed by a 
child element of the same name, whereupon the context attribute could be 
used on that element.  Like this:

<bind nodeset="c">
    <calculate context=".." value="a + b"/>
</bind>

This has several benefits.

First, it is easier to say that the *bind* identifies the nodes to which 
MIPs are applied, whereas the <calculate> element is only concerned with 
providing a more sophisticated way of expressing the formula.  There is no 
confusion about what node the formula applies to because the context 
attribute is not being placed on an inner bind.  In other words, it is 
easier to say that context on the calculate element only overrides the 
evaluation context of the value attribute and does not interfere in any 
way with the node to which the result of the formula is applied.

Second, it allows us to simplify the expression of boolean results.  For 
example, must we really call boolean-from-string() on expressions whose 
result is known to be boolean?  Specifically, the element relevant could 
be defined as automatically applying boolean-from-string to the string 
result of the value attribute in the following:

<bind nodeset="node/a">
    <relevant context=".." value="b"/>
</bind>

It's up to the group to decide if they want this extra semantic for 
relevant, readonly and constraint, but lots of people consistently forget 
to put boolean-from-string() until they get burnt by it.  Even if we used 
'boolean' rather than 'value', it would be better, e.g.

<bind nodeset="node/a">
    <relevant context=".." boolean="b"/>
    <readonly context=".." boolean="c"/>
</bind>

Third, using MIP named child elements allows the possibility for 
combinators on some of the MIP types, especially constraint, e.g. the 
following would say that node a is invalid unless (b and c and (d or e) 
and (not f)):

<bind nodeset="node/a">
    <constraint context=".." operator="and">
          <constraint boolean="b"/>
          <constraint boolean="c"/>
          <constraint operator="or">
                 <constraint boolean="d"/>
                 <constraint boolean="e"/>
         </constraint>
         <constraint operator="not" boolean="f"/>
    </constraint>
</bind>