Re: @if and @src (on bind), and submodels

My first reaction to @if on bind was similar to Mark's. 

But having a chance to sleep on it, I began to feel that I was 
interpreting 'if' with too little of a declarative mindset based on a 
predisposition to view 'if' as a semantic attached to our (imperative) 
actions.

This use of 'if' on bind is even more declarative than the XForms use of 
switch and case, and as Mark has noted the 'relevant' attribute cannot be 
used.

There aren't any use cases at the run-time level that can't be solved with 
an XPath predicate instead, but the use of 'if' (or something like it) on 
bind does give more information at the XML level (than an XPath predicate) 
of the the author's intent to have binds that apply MIPs conditionally. 
But, there is an efficiency problem if a page has to provide an 
xforms-model-construct-done handler that selects the appropriate binds 
after the model has been constructed.  The binds I don't want in a 
particular page are created and then destroyed.

Thus, having also the option of @src on bind is important to the use case 
of having a set of web pages that work together to fill out a data 
instance.  In that use case, I would have something like this:

Resource: data.xml (a server-side data resource mutated by the user as 
data is collected)

<data> <A>...</A> <B>...</B> <C>...</C> </data>

File: constraints.A.xml (a set of constraints for the data collected by 
page A)
File: constraints.B.xml (a set of constraints for the data collected by 
page B)
File: constraints.C.xml (a set of constraints for the data collected by 
page C)

File: page.A.html (web page A, collects data for A)

<model>
   <instance src="... data.xml"/>
   <bind src="constraints.A.xml"/>
</model>

File: page.B.html (web page B, collects data for B)

<model>
   <instance src="... data.xml"/>
   <bind src="constraints.B.xml"/>
</model>

File: page.C.html (web page C, collects data for C but also must submit 
the completed data)

<model>
   <instance src="... data.xml"/>
   <bind src="constraints.A.xml"/>  <!-- can be avoided with careful 
design -->
   <bind src="constraints.B.xml"/>  <!-- can be avoided with careful 
design -->
   <bind src="constraints.C.xml"/>
</model>

In page C, the constraints for A and B can be avoided with careful 
application design because the user doesn't get to page C until those 
constraints are met during the fill experiences for A and B.  Only if data 
entry in C can cause violation of those constraints are they needed in 
page C, but this is not typically what happens, so a great deal of 
efficiency is obtained on each page by enforcing only the constraints for 
data collected on that page.

Of course, if it can be avoided, then why bother with @src on bind.  The 
answer is that often the parts A, B and C are used in more than one web 
page collection.  It helps to be able to create them as external reusable 
components from which multiple larger form applications can be 
constructed.  Then, if the schema for a part (A, B or C) changes, then the 
constraints for the same part can be modified in one place and all form 
applications which use that modified part automatically get the modified 
constraints.

A more specific use case helps drive out more requirements.  Suppose the 
reusable component I want is for an address block.  One issue is that an 
address block can occur at different places within different schema, and 
in fact you might get more than one address block in the same schema 
instance.  So, I'd be inclined to use bind with @src and @nodeset at the 
same time:

<bind nodeset="shipTo" src="constraints.address.xml"/>
<bind nodeset="billTo" src="constraints.address.xml"/>

Finally, note that this is only getting at how we might create reusable 
sets of binds, rather than reusable model fragments.  Since the components 
of a model (instances, binds, actions, submissions) are intended to work 
together, often what one needs is to be able to pull in a whole submodel, 
not just a collection of binds.  The example here is all the baggage 
needed for a web service.  For example, suppose you have web service 
endpoints foo and bar:

foo.xml:
<model>
    <instance id="SOAPRequest_foo">...</instance>
    <instance id="SOAPResponse_foo">...</instance>
    <submission id="Request_foo" ... />
</model>

bar.xml:
<model>
    <instance id="SOAPRequest_bar">...</instance>
    <instance id="SOAPResponse_bar">...</instance>
    <submission id="Request_bar" ... />
</model>

They can be consumed in lots of web pages like this:

<model>
    <instance id="data"> ... </data>
    <model id="foo" src="foo.xml"/>
    <model id="bar" src="bar.xml"/>

    <action ev:event="xforms-submit" ev:target="Request_foo">Copy some 
data to SOAPRequest_foo</action> 
    <action ev:event="xforms-submit-done" ev:target="Request_foo">Copy 
some data from SOAPResponse_foo</action> 

    <action ev:event="xforms-submit" ev:target="Request_bar">Copy some 
data to SOAPRequest_bar</action> 
    <action ev:event="xforms-submit-done" ev:target="Request_bar">Copy 
some data from SOAPResponse_bar</action> 

    ...
</model>
...

Notice that I simply assume that the internal models will just contribute 
their content to the outer model.  I would go so far as to say that any id 
attributes on inner models are simply not accessible from the model 
attribute of the UI binding, but that the use of an id on the inner model 
that has the src attribute provides us a way of dealing with ID space 
conflicts.  Referencing the imported instances could be done by 
concatenation of the model id with the instance id.  For example, the 
action that copies data too SOAPRequest_foo would actually use XPaths that 
start with instance('foo.SOAPRequest_foo')/...

This is the point where Erik might suggest we use XInclude, though the 
above minimalist semantics added to the XForms namespace seem more likely 
to promote short term multiple implementations than does ingesting another 
W3C spec with all its extra baggage.  But either way, hopefully this at 
least provides a clearer picture of the things we need to be able to do.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Mark Birbeck <mark.birbeck@webbackplane.com>
To:
"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>
Cc:
public-forms@w3.org
Date:
06/12/2009 03:53 AM
Subject:
Re: @if and @src



Hi Leigh,

> [...]
>
> Add @if to all elements except...
>
> [...]

Nice idea, but could I suggest that we don't use @if? The problem is
that it's used on actions, so you have to add an extra step in your
mental process when reading someone's markup, to decide whether what
you are looking at is an action or not.

I think in general it's better to name something as close as possible
to what it is. Even if we later spot common factors and shift the name
slightly, that first step avoids confusion.

So in this case I would say that something like @relevant would be
more fitting for most of your examples:

  <elt ref="x" relevant="pred" /> --> <elt ref="x[pred]" />
  <elt nodeset="x" relevant="pred" /> --> <elt nodeset="x[pred]" />

  <select ref="abc">
    <label>ABC</label>
    <choices>
      <item relevant="../def = 1">
        <label>Hi</label>
        <value>Hi</value>
      </item>
    </choices>
  </select>

We've been talking about 'on the glass' attributes for a while now, so
your proposal fits nicely with that, and you can imagine having
@readonly, etc., as well.

I don't think using @relevant works so well for the bind example that
you gave, though; if you really think that's a useful scenario then I
think it would need a different attribute.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)