FW: Response to your XForms comment (0164)

Re-send to correct address for archival. -m

-----Original Message-----
From: Micah Dubinko 
Sent: Thursday, October 10, 2002 5:38 PM
To: 'paul@prescod.net'
Cc: 'w3c-forms-editor@w3.org'
Subject: RE: Response to your XForms comment (0164)


Hi Paul,

I think we're getting there.

Your issue, as I understand it, can be summarized as follows:

In XForms, it is possible through a convoluted (though currently legal) set
of binding expressions, to get inconsistent minOccurs or maxOccurs
properties on a repeat set. For example:

<items>
  <item>
  <item>
  <item>
</items>

where the first <item> ends up with minOccurs="1", the second no minOccurs
property at all, the third with minOccurs="2", or whatever. When the
constraints on a repeat set are inconsistent, what is the correct behavior?
And should the inconsistent state be allowed in the first place?

You asked:
>is there anything that requires the binding *expression* to address 
>a homogenous collection?

No, by design. To date, we have placed minimal restrictions upon binding
expressions in general.

><bind nodeset="//*[@foo='bar']" required="true()" />
><bind nodeset="//*[@foo='bar']" minOccurs="0" maxOccurs="4" />

These are both legal XForms statements. The question on the second one is,
a) should it be legal? and b) how should it behave?


You have identified a genuine problem with the spec, and we are hesitant to
make an arbitrary decision. Nevertheless, would you agree to the following:?

1. We agree that this is a problem. Thank you for pointing it out!
2. We agree to fix it with the following spec changes:

* We remove the 'nodeset' and 'model' attributes from <repeat> and
<itemset>, leaving only the 'bind' attribute for binding (also removed:
repeat-model and repeat-nodeset)

* With this change, the nodeset selected by <bind> and the repeat set will
always match. The "homogeneous collection" rules would then apply to any
<bind> nodeset used this way. Also, it's no longer possible to have
conflicting minOccurs and maxOccurs properties.

* Several examples, as well as the Schema for XForms will change. Possibly
other minor editorial changes needed following the spirit of the above 

3. This is subject to approval by the XForms Working Group. We need both you
and us to agree to this to declare victory.

Please respond to state whether you agree with this proposed Resolution.

Thanks!

.micah


-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Thursday, October 10, 2002 3:46 PM
To: Micah Dubinko
Subject: Re: Response to your XForms comment (0164)


I understand you want to move on to CR but I think that there are things 
that you mean to say in the spec but don't say aloud. In order to 
expedite things I'll try to provide sample language of what I think a 
fix is.

Micah Dubinko wrote:
>...
> minOccurs and maxOccurs can be placed anywhere, but they only have an
effect
> for "repeating" items, which means a <repeat nodeset="x"> or <itemset
> nodeset="x">.
> 
> The node-set selected by such repeating sets is required in the spec to be
a
> "homogeneous collection" [defined in 9.3.1 The repeat Element]:

But is there anything that requires the binding *expression* to address 
a homogenous collection? I don't see that in the section on binding 
expressions. Isn't it perfectly valid to have a binding expression that 
selects non-contiguous nodes:

<bind ref="//*[@foo='bar']" required="true()" />
<bind ref="//*[@foo='bar']" minOccurs="0" maxOccurs="4" />

If it isn't, where does it say that? If minOccurs/maxOccurs rules should 
use the same XPaths as in the repeat element, it should say that. If I 
am allowed to do expressions like that then I can select and add 
properties to nodes that don't exist.

I propose that what you want to add is: "the ref attribute must contain 
an XPath identical to one in the nodeset attribute of a repeat element" 
or something like that.

> "This node-set must consist of contiguous child element nodes, with the
same
> local name and namespace name of a common parent node."

What does "namespace name of a common parent node" mean? Is it trying to 
say something already implied by "contiguous child element nodes?" I'm 
afraid to ask what "contiguous" means in the face of insignificant and 
significant whitespace, text nodes, processing instructions and comments.

Perhaps: "This node-set must consist of contiguous nodes that are all of 
type element, with the same local name and namespace name (or all have 
no namespace name)."

As an aside, why does homegeneity even matter? I understand why 
contiguousness might matter so that you know where to do insertions. But 
what is the benefit of homogeneity? It seems like a meaningless 
restriction, especially since I can address things by their attributes 
or position rather than their localnames and namespace names (as per 
above). I won't raise this as a formal issue because it is just a matter 
of being restrictive for no purpose.

  Paul Prescod

Received on Thursday, 10 October 2002 20:39:07 UTC