RE: problems with <xf:insert />

Hi,

I think the limitation you described for insert/@nodeset (as in example //y)
also applies to insert/@parent as well. And then, the meaning of @nodeset is
'same' as @parent (Correct me if I'm wong). If we assume that the
instance-template always has one instance node in its nodeset, then
insert/@newChild would be implied...One may interpret it as a
predicate-stripped location path of nodeset. However, with insert/@newChild
or insert/@clone attribute, as you are saying, authors will have more
control.

Regards,
Shailesh Karandikar
Dendrite, R&D.

-----Original Message-----
From: Paul Butcher [mailto:Paul.Butcher@x-port.net]
Sent: Thursday, February 06, 2003 10:34 AM
To: 'www-forms@w3.org'
Subject: problems with <xf:insert />



There are some troublesome aspects to the behaviour of the insert element.
http://www.w3.org/TR/2002/CR-xforms-20021112/slice9.html#action-insert

In the following simple example, we must copy the last <y /> child of <x />
in the initial instance, and insert it into the live instance under <x />.

	<xf:insert nodeset="x/y" />

There are two options for cloning, the required node can be cloned either on
request, or in the initialization phase and stored.  Either method is fine.
For the insert location, however, this must be stored at initialization
time.  If all <y /> nodes are deleted at runtime, the XPath statement "x/y"
will no longer bind to a homogenous collection, so the insert location
cannot be resolved.  You may suggest that the parent node could be derived
from the XPath statement by removing "/y" to return "x", but consider the
following statement:

	<xf:insert nodeset="//y" />

If the author knows that there somewhere in the document, there is a node
that contains all of the <y /> elements, then this will return a homogenous
collection.  If all of those <y /> elements are deleted, there is no longer
any way of finding that parent.


The problem with resolving either insertion point or template node at
initialization time can be illustrated below:

	<xf:insert nodeset="x[position()=/*/@n]/y" />

Here, the author wishes to resolve both nodes, conditional on the value of
another node.  Is that other node live, or from the initial instanceData?
In order for it to make sense in XPath, it must be from the same document as
the required resulting node. That means, that for determination of
node-to-clone, it must be from the initial, but for determination of
insertion point, it has to be live.  

This is contrary to the needs outlined above, where insertion point must be
resolved during initialization.  It is also wrong, since the collection
pointed to in the initial instance data is not really the "corresponding
node-set" to the live one.  In order for the real corresponding node-set to
be returned, some nodes referred to in square brackets in the XPath
statement must be live, but others may have to be resolved in the initial
instance data. 

One way around this is simply to resolve both nodes in the live
instanceData.  If an attempt is made to insert into an empty nodelist, the
processor should give an error.  This would keep the behaviour approximately
the same as the spec, but remove the interpretation difficulty.  This is the
current behaviour of Formsplayer.  However, this approach has limitations.

Often, an author can have little or no control over the format of the XML in
an instance, it may come from a Web Services query or a database belonging
to another organisation.  In this situation, it would be impossible for
XForms to insert data into an empty list without resorting to programmatic
access to the DOM via a script written by the forms author.  


We propose that a better solution would be to resolve the insertion point
with one XPath statement, pointing to the node into which the new node will
be inserted, and node-to-insert with another statement, specifying the node
to copy.  This would also facilitate cross-instance copying of data,
allowing XForms to populate lists with no initial members.

The format for insert could be:

<xf:insert 
	newChild="XPATH" 
	parent="XPATH" 
	at="XPATH" 
	position="before|after" 
/>



Paul Butcher
FormsPlayer Lead Programmer
x-port.net Ltd.
4 Pear Tree Court
London
EC1R 0DS

Try our XForms plug-in for IE
at http://www.FormsPlayer.com/


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Received on Thursday, 6 February 2003 13:11:59 UTC