RE: evaluation context

> > We ourselves have discovered that we need a way to merge the "xform"
> > attribute with the "ref" and "nodeset" attributes, but we 
> simply haven't
> > figured out how to do that yet.
> 
> What about removing the xform attribute and introducing a new 
> XPath function
> that returns the xform:instance node ?
> Something like: node xformInstance("id_of_form")

this or something similar is in fact the plan. The devil's in the
detail, though.

> That way, one could write such expressions:
> <xform:repeat nodeset="/one/path">
>     <xform:input ref="/input">
>         <xform:caption>
>             <xform:output
> ref="xformInstance('not_default_instance')/other/path/caption" />

Weeell... this example is precisely one of the more tricky cases. I do
remember extended discussions about having form controls inside captions
- or more precisely, about prohibiting them. What is the use or need (or
meaning) of having, say, a xf:input _inside_ a xf:caption? or inside a
xf:help or xf:hint? We do have open content models for these three
because we believe that for the integration in other markup languages,
it doesn' make sense to disallow markup from _these_ languages (like for
example XHTML). In the group, we are pretty convinced that XForms inside
caption, help and hint does not make sense.

What do you think about that?

>         </xform:caption>
>     </xform:input>
> </xform:repeat>
> 
> Another question concerning context: is there a mean to use 
> only the bind
> attribute instead of the ref attribute in the preceding exemple ?

Unless I've missed a subtle point, that's the idea of the bind
attribute: to be a simple replacement for ref+nodeset so that the UI
designer doesn't have to write lengthy XPaths all the time. 

Side remark: At the same time, the bind attribute allows for a
well-defined interface between a UI designer and a application
programmer. The UI designer can build the UI without worrying about the
actual paths, she would just work based on a list of bind IDs to use. At
the same time, the app programmer can develop his applications and
provide such a list - that way, the interface between the two is
well-defined - and the app programmer may change the structure of the
data at any time without affecting the UI.

Hope this helps,

Josef

Received on Friday, 19 October 2001 06:23:41 UTC