W3C home > Mailing lists > Public > public-forms@w3.org > February 2009

Re: Issue with test 10.3.j

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 16 Feb 2009 23:07:17 -0800
To: Erik Bruchez <ebruchez@orbeon.com>
Cc: Forms WG <public-forms@w3.org>
Message-ID: <OF3C888DAC.FAC4DB01-ON88257560.0026DD23-88257560.00270F56@ca.ibm.com>
I agree with Erik that the test is wrong.  Further, the test should switch 
to testing that the insertion of the attribute does *not* occur (NO-OP) 
because we already have the test for appendix B4 which test that the 
attribute insertion does occur when the context attribute is used.

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:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
02/16/2009 10:53 AM
Subject:
Issue with test 10.3.j



All,

I believe that this test is incorrect. It contains three inserts
similar to this one:

<xforms:insert origin="instance('second')/item_list/item[1]/@price"
                nodeset="instance('first')/item_list/item[1]" />

The test expects that the attribute pointed to by the @origin
attribute is added to the element pointed to by the @nodeset
attribute. It is my understanding that this must not happen, and here
is why:

* The "insert location node" is element item[1] in instance
   "first".

* Then, "the insert location node provided by the Node Set Binding and
   optional at attribute is intended to be the sibling of the cloned
   node". This means that the attribute is intended to be a *sibling*
   of the item[1] element, which of course is not possible.

* Therefore we fall under the condition: "If a cloned node cannot be
   placed at the target location due to a node type conflict or because
   the target location is undefined, then the insertion for that
   particular cloned node is ignored."

This behavior was intentionally specified to consistently
differentiate between the insertion of siblings vs. children. Broadly:

* If one or more nodes result from @nodeset evaluation, then cloned
   nodes are inserted "next to" the nodes specified. (The root element
   is a border case exception.)

* Otherwise, if a node results from @context evaluation, then cloned
   nodes are inserted "within" the node specified.

So the test should be modified to:

<xforms:insert origin="instance('second')/item_list/item[1]/@price"
                context="instance('first')/item_list/item[1]" />

Alternatively, we could maybe keep test 10.3.j as is but make sure we
test that it NOPs, and create 10.3.k to test the proper insertion with
@context.

Note that example "B.4 Set Attribute" in the spec shows the correct
usage with @context.

Also, I believe that one implementation reported passing the broken
test.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Tuesday, 17 February 2009 07:07:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:50 UTC