W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

Re: Questions about generating new ids on insert

From: David Landwehr <david.landwehr@solidapp.com>
Date: Wed, 31 May 2006 14:15:43 +0200
Message-ID: <447D88EF.3050700@solidapp.com>
To: Allan Beaufour <beaufour@gmail.com>
Cc: www-forms <www-forms@w3.org>

Hi Allan

I have read the text as you generate a unique ID when the node you are 
cloning has the type xsd:ID, e.g. that this is part of the cloning 
process and that it is the source element's type that determines if the 
content should get a new unique ID. This will also solve the problem 
when the author immediately after insert changes the ID (in deferred the 
node will not even generate xforms-valid and xforms-invalid).

That this is done in the process of cloning is written in the 
specification:
"The new node is created by cloning the final member of the homogeneous 
collection. In this process, nodes of type |xsd:ID| are modified to 
remain as unique values in the instance data."

Best regards,
David


Allan Beaufour wrote:
>
> The specification of the instance element includes this sentence:
> "In this process, nodes of type xsd:ID are modified to remain as
> unique values in the instance data."
> [http://www.w3.org/TR/2006/REC-xforms-20060314/slice9.html#action-insert]
>
> To that, I have a few questions.
>
> 1) When exactly is this modification taking place?
>
> It matters since nodes might have types associated through <xf:bind
> type=""/>, so these needs to be processed before the nodes actually
> are of type xsd:ID (I guess this takes place during xforms-rebuild.)
>
> But should it take place before or after xforms-recalculate? Before,
> since the form author might want to do calculations based on the
> (possibly new) value? Or after, since the form author might want to
> calculate a new id himself?
>
> If it takes place as "part of" the RRR process, then it needs to be
> deferred too, which might be tricky -- at least from an implementation
> perspective.
>
> 2) Does it adhere to the readonly MIP, ie. does not change readonly 
> nodes?
>
> The form author might, for some reason, not want the nodes to be
> changed, and could thus set readonly="true()" for those nodes to avoid
> that.
>
> 3) Is it on purpose that it is stated as strict as "remain as unique
> values in the instance data"?
>
> Should it have been more like the generate-id() function from XSLT,
> which includes:
> "There is no guarantee that a generated unique identifier will be
> distinct from any unique IDs specified in the source document."
> [http://www.w3.org/TR/xslt#misc-func]
>
> 4) Does the modification follow the normal XForms rules of how to set 
> values?
>
> F.x. for an element, should it only set the first text node child?
>


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------
Received on Wednesday, 31 May 2006 12:15:30 GMT

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