W3C home > Mailing lists > Public > www-forms@w3.org > April 2007

Re[2]: <repeat/> Element

From: Ivan Latysh <IvanLatysh@yahoo.ca>
Date: Sat, 14 Apr 2007 09:22:27 -0400
Message-ID: <1991133934.20070414092227@yahoo.ca>
To: www-forms@w3.org

Hello Peter,

Friday, April 13, 2007, 11:22:20 PM, you wrote:

> Ivan,
> I think the wording of point 2 is not that the nodes must have a common 
> parent, rather the namespace must be the same. (or that is how I see it)
> consider:
[skipped]
> However the nodeset is not consistent in respect to a repeat element as 
> it violates rule 2 in that orange and safron do not share a common 
> namespace.
[skipped]
> which is consistent with rule2. 
> While this is a constructed example it serves to illustrate the meaning 
> of the specification.
> While the specification says the behavior is non-deterministic, my 
> personal view is that when an xpath returns a collection of nodes that 
> do not share a common namespace then a binding error should occur.
Why would node set containing nodes from different name-spaces should be considered as error?

I don't see anything wrong with it, and to be precise name-spaces are XPath business.
We are processing XML data, so why do we introduce synthetic restrictions that contradict
XPath?

This is why we are talking right now, XForms is dynamic XML processing language, but the spec has
all this little flaws that makes it wrong. If we process XML and use XPath - so we must obey XPath
terminology and spec.
Having XForms well integrated with XML, XPath makes it very powerful technology.

Let me repeat myself again, if XForm well designed you won't see projects like http://exforms.org
hanging around. Having this project survive for so long prove that XForms crying out to be fixed.

I can see that spec look at the problem from Object Oriented point of view, when in reality it is
dynamic XML processing.

-- 
Best regards,
 Ivan                            mailto:IvanLatysh@yahoo.ca
Received on Saturday, 14 April 2007 13:28:03 GMT

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