W3C home > Mailing lists > Public > www-forms@w3.org > October 2001

RE: evaluation context

From: Josef Dietl <josef@mozquito.com>
Date: Fri, 19 Oct 2001 12:23:10 +0200
Message-ID: <D0F1529EE943B3449F755CA1A40887464E0FE2@winserver.windomain.mozquito.com>
To: Jérôme Nègre <jerome.negre@ecl2000.ec-lyon.fr>, <www-forms@w3.org>, <w3c-forms@w3.org>
> > 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:50 GMT