Re: Custom event context information

Nick,

Thanks for the feedback.

> I have general remark on using the select attribute instead of  
> nodeset is that when we are going to allow XPath 2.0 there are also  
> use cases for allowing sequences of item() instead of a nodeset as  
> we know it today for repeat. So I'm not really sure what the best  
> solution for this is, introducing a new attribute that supports  
> item()* or relax the value space of nodeset. I know that the name  
> nodeset hints a set or sequence of node() but on the other hand  
> introducing a new attribute for item()* complicates XForms.

Maybe we should think about the bigger issue of binding/selection  
attribute proliferation in XForms. We have

* @model
* @ref
* @nodeset
* @bind
* @value
* @context
* And possibly a new attribute like @select to express item()*

That's a lot of attributes! Do we have a way out of it?

I think it would be wrong (tm) to use @nodeset to refer to anything  
but an actual node-set!

Note that with XPath 2.0, a mechanism to select item()* is also needed  
for variables, and could also be used by itemset:

<itemset select="(1 to 20)">
   <label value="."/>
   <value value="concat('value-', .)"/>
</itemset>

Or even:

<itemset select="(1 to 20)">
   <label select="."/>
   <value select="concat('value-', .)"/>
</itemset>

Another solution could consist in using @value all the way. There are  
two drawbacks to this:

* In XForms, @value is currently always used to express that the  
result is used a string.
* For variables, if XForms has <variable name="..." value="..."/>,  
then it is confusing for people used to XSLT.

>> Should the element support the "model", "ref", "value", "bind"  
>> attributes as well?
> If we do not introduce a new select attribute I think we should also  
> support "model", "ref", "value", "bind" (I think model should be  
> supported either way)

Either way we could support all single-node binding attributes. They  
would simply determine the context evaluation node for the value. In  
fact, this is what we do in our implementation for xforms:variable. So  
you could write:

   <context model="my-model" ref="names" select="string-join(name, ',  
')"/>

>> Can we support a QName for the context information name?
> I agree that this should be names according to the DOM-Level-2- 
> Events spec (are mapped to members in JavaScript for example), and  
> therefore we can't allow QNames because other consumers won't be  
> able to handle our events.

Sounds reasonable. We support QNames in our implementation, but it  
seems like we shouldn't if we want to remain compatible with DOM!

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Friday, 19 June 2009 17:53:08 UTC