Scoped resolution of model attribute for binding elements

The attached document contains a thread from www-forms@w3.org mailing list
that lead to this message.

The latest working draft has resulted in some ambiguity on how the model for
binding elements is selected when no model attribute is specified in
multi-model situations. Specifically, "7.3 Evaluation Context" leads the
reader to believe that the XPath context node can be used to determine the
current model while "3.2.3 Single-Node Binding Attributes" and "3.2.4
Node-Set Binding Attributes" require a model reference to be declared
explicitly if multiple models exist in the containing document.

This email proposes that the default model of a binding element be inherited
from ancestor elements where possible. Adoption of the method described
below provides authors of XForms document with an intuitive and elegant
design that is consistent with XML namespaces and XPath context nodes (i.e.
model selection uses scoped resolution). 


Proposed Model Selection Process:

The model for any binding element can be established by evaluating the
expression "ancestor-or-self::node()/@model". If the resultant nodeset
contains at least one node, the value of the first node in the nodeset is to
be used. If the resultant nodeset is zero in length, the first model in
document order is to be used.

In short, the model for any binding element can be determined by following
the sequence:

1. The binding element's model attribute is used.
2. The nearest ancestor binding element's model attribute is used.
3. The first model in document order is used.


These rules should apply to all elements with either "Single-Node Binding
Attributes" or "Node-Set Binding Attributes". 


Suggested Editorial Revisions:

Section 3.2.3 and 3.2.4, the paragraph that reads:

"XForms Model selector. Optional when a containing document contains only
one XForms Model, otherwise required, except when the bind attribute is
present, in which case this attribute has no meaning."

should be changed to:

"XForms Model selector. Specifies the id of a Model to associate this
binding element with. If no model attribute is specified, the nearest
ancestor binding element's model attribute must be used. In the absence of a
model attribute on any ancestor binding element, the first Model in document
order must be used. "

As a supplement to the argument above, the following examples may be used to
illustrate how scoped resolution improves the readability of XForms markup
in multi-model situations.

<xf:model id="form1">
	<xf:instance>
		...
	</xf:instance>
</xf:model>

<xf:model id="form2">
	<xf:instance>
		...
	</xf:instance>
</xf:model>

...

<xf:group model="form1">
	<!-- 
	all child binding elements inherit groups model
	removing redundant model attributes for each.
      -->
	<xf:input ref="doc/foo">
		<xf:caption>foo</xf:caption>
	</xf:input>
	<xf:input ref="doc/bar">
		<xf:caption>bar</xf:caption>
	</xf:input>
</xf:group>


<xf:repeat model="form2" nodeset="some/nodeset">
	<!-- 
	all child binding elements inherit repeat's model
	removing redundant model attributes for each.
      -->
	<xf:input ref="foo">
		<xf:caption>foo</xf:caption>
	</xf:input>
	<xf:input ref="bar">
		<xf:caption>bar</xf:caption>
	</xf:input>
</xf:repeat>

Previous drafts stated that if no model attribute was specified, the first
model in document order was to be used as default. This caused problems for
authors as they assumed models would propagate to child elements:

<xf:repeat model="form2" nodeset="some/nodeset">
	<!-- 
	child binding elements still reference form1 even though
	ancestor repeat uses form2. Non-intuitive.
	-->
	<xf:input ref="foo"/>
</xf:repeat>

The current draft states that the model must be specified on all binding
elements in multi-model documents. This seems like overkill. The model is
easily established by interrogating ancestor elements.

<xf:repeat model="form2" nodeset="some/nodeset">
	<!--
	must specify model on each child even though ancestor
	specifies.
	-->
	<xf:input model="form2" ref="foo"/>
</xf:repeat>

Thanks,

- Ryan Tomayko

Sterling Commerce

attached mail follows:

Micah Dubinko wrote:

> One gotcha:
>
> >I believe the
> >model for any form control should be determinable by evaluating the 
> >XPath expression "ancestor::*/@model".
>
> When you say this, you're talking about applying this theoretical XPath 
> expression to the containing document (and not instance data), right?

Yes.

> As long as that's the case, and if the produced nodeset is size > 1 you
use
> only the first node, that looks like a good rule.

Will make sure to mention first node rule in message to
www-forms-editor@w3.org.

> And if that expression produces an empty node-set, then either:
> 1) you have only one model in your containing document, and everything is
OK 
> (defaulting to the one-and-only model present), or
> 2) you nave more than one model, and your form is in error

That sounds good. An alternative to #2 would be to default to the first
model in document order if no model is specified on ancestor-or-self
elements. In which case the two rules above could be combined as:

If evaluation of the expression "ancestor-or-self::*/@model" produces a zero
length nodeset, the form control should default to the first model in
document order. 

This works in single and multi model situations. What do you think?

- Ryan


-----Original Message-----
From: Micah Dubinko [mailto:MDubinko@cardiff.com] 
Sent: Monday, August 26, 2002 5:41 PM
To: Tomayko, Ryan; www-forms@w3.org
Subject: RE: absolute/relative ref and model-ref 'inheritance'


Ryan Tomayko wrote:

>If you wish, I would be happy to make specific editorial suggestions 
>for each place in the specification that I see possibility for 
>ambiguity on
this
>matter.

I'll take you up on that. Please make some specific suggestions, and mail to
www-forms-editor@w3.org.

One gotcha:

>I believe the
>model for any form control should be determinable by evaluating the 
>XPath expression "ancestor::*/@model".

When you say this, you're talking about applying this theoretical XPath
expression to the containing document (and not instance data), right?

As long as that's the case, and if the produced nodeset is size > 1 you use
only the first node, that looks like a good rule.

And if that expression produces an empty node-set, then either:
1) you have only one model in your containing document, and everything is OK
(defaulting to the one-and-only model present), or
2) you nave more than one model, and your form is in error

Thanks!

.micah


-----Original Message-----
From: Tomayko, Ryan [mailto:Ryan_Tomayko@stercomm.com]
Sent: Monday, August 26, 2002 11:58 AM
To: www-forms@w3.org
Subject: RE: absolute/relative ref and model-ref 'inheritance'



Micah,

On the topic of model inheritance, I would like to suggest that this be made
more clear in the draft. I agree with your answer completely (and have
implemented as such) but the draft is not explicit. 

From just section 7.3 "Evaluation Context", it makes perfect sense: the
model for children elements is inherited from ancestor elements just like
the context node. That is intuitive and follows a common system used by
namespaces and XPath context nodes (i.e. context information is inherited
from ancestors). 

However, under 3.2.3 "Single Node Binding Attributes" documentation on the
model attribute states:

"
model attribute
Optional when a containing document contains only one XForms Model,
_otherwise required_, except when the bind attri<snip>."

This seems silly. If the model is inherited along with the context node, why
do I have to specify a model for each form control? 

The previous revision of the recommendation stated that the first model (in
document order) would be used if no model attribute was explicitly
specified. That is also flawed, IMO. The model for any form control should
be obvious based on the context node. 

Even in the absence of a context node (which is impossible), I believe the
model for any form control should be determinable by evaluating the XPath
expression "ancestor::*/@model". The only time a model attribute should be
required is when you want to switch to a model other than that which
contains the context node. 

If you wish, I would be happy to make specific editorial suggestions for
each place in the specification that I see possibility for ambiguity on this
matter.

Thanks,

- Ryan Tomayko

Sterling Commerce


-----Original Message-----
From: Micah Dubinko [mailto:MDubinko@cardiff.com] 
Sent: Monday, August 26, 2002 1:04 PM
To: 'Jerome Negre'; Kurt George Gjerde; www-forms@w3.org
Subject: RE: absolute/relative ref and model-ref 'inheritance'



Hi Kurt,

-1-

As Jerome pointed out, this is an invalid XForms Model by the latest draft.
You could either assemble a single-rooted instance, or have two instances.

<model>
  <instance id="project">
    <name>...</name>
  </instance>

  <instance id="person">
    <name>...</name>
  </instance>
</model>
Then you could skip the whole <group> in the UI (unless you wanted it for
namespace defaulting), and write:

<input ref="instance('project')">
  <label>Project name</label>
</input>
and
<input ref="instance('person')">
  <label>Person name</label>
</input>

(Note that this example, like your original, cheats on namespaces. Normally
the XForms elements and the instance elements would be in different
namespaces)

-2-

An XPath context node is by necessity in a certain 'document'. So, yes,
'fishpond'.

-3-

Each model keeps track of its context node.

<group model="mod-pond">
is really no different than
<group model="mod-pond" ref=".">

So this example would also work as you expect, pointing to /size/depth for
the 2nd <input> control.

Thanks!
.micah

-----Original Message-----
From: Kurt George Gjerde [mailto:kurt.gjerde@intermedia.uib.no]
Sent: Monday, August 26, 2002 7:16 AM
To: www-forms@w3.org
Subject: absolute/relative ref and model-ref 'inheritance'

Hi,

A few questions about absolute/relative xpaths in @ref,
and about model reference "inheritance".


-1- ref

Take this form:

  <model>
    <instance>
      <project>
        <name>XForms 1.0</name>
      </project>
      <person>
        <name>Janet</name>
      </person>
    </instance>
  </model>
  ...
  <group ref="project">
    <input ref="name">
      <label>Project name</label>
    </input>
    <input ref="/person/name">
      <label>Person name</label>
    </input>
  </group>

I assume that

  'Project name' will be "XForms 1.0"
  (ref 'project' + relative ref 'name' = /project/name)

  'Person name' will be "Janet"
  (absolute ref = /person/name).

Correct? This seems logical to me (see 9.1.1, also quoted below) but I've
seen implementations rendering the second input's ref as
/project/person/name (or /project//person/name!) (ignoring the initial slash
in the @ref).


-2- model

About the @model attribute the (new) WD says (3.2.3): "required, except when
the bind attribute is present".

The group UI element can take single node binding attributes; WD says
(9.1.1): "The binding expression is *solely* for the purpose of authoring
convenience; it allows controls appearing within element 'group' to use
relative XPath expressions." Doesn't mention model, and model isn't xpath...

Now, are model references 'inherited' down to child element controls? Or do
they have to be explicitly set for each and every control?

  <model id="city"/>
  <model id="fishpond"/>

  <group model="fishpond">
    <input ref="size"/>
  </group>

Would this be 'size' in the 'fishpond' model or in the default model
('city')? The former I hope.


-3- both

If it's the size of the fishpond...

Take the following form:

  <model id="mod-ocean">
    <instance>
      <size>
        <width>vast</width>
      </size>
    </instance>
  </model>

  <model id="mod-pond">
    <instance>
      <size>
        <depth>200mm</depth>
      </size>
      <depth/>
    </instance>
  </model>

  <group ref="size">

    <input ref="width">
      <label>Ocean width</label>
    </input>

    <group model="mod-pond">
      <input ref="depth">
        <label>Pond depth</label>
      </input>
    </group>

  </group>

Would the @ref in the second input ('pond depth'; in model mod-pond) be
relative to the @ref in the top group element? Would it be
{mod-pond}/size/depth or just {mod-pond}/depth?

I assume (and hope) the former is correct, and that this is just a weird
example (you get what you ask for).



Very grateful for any input,
-Kurt.
__________
kurt george gjerde <kurt.gjerde@intermedia.uib.no>
intermedia uib, university of bergen