- From: David Landwehr <david.landwehr@solidapp.com>
- Date: Wed, 31 May 2006 14:15:43 +0200
- 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 UTC