- From: Innovimax SARL <innovimax@gmail.com>
- Date: Wed, 28 Nov 2007 14:09:49 +0100
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
On Nov 26, 2007 10:59 PM, Norman Walsh <ndw@nwalsh.com> wrote: > / "Innovimax SARL" <innovimax@gmail.com> was heard to say: > | On Nov 26, 2007 4:23 PM, Norman Walsh <ndw@nwalsh.com> wrote: > |> / Innovimax SARL <innovimax@gmail.com> was heard to say: > |> |> | === p:uuid === > |> |> > |> |> I don't understand what you're asking. > |> | > |> | Well my point was : why isn't just UUID a possible value of the > |> | "scheme" option in p:label-elements ? > |> > |> That would be a new feature, are you suggesting that we should add it? > |> UUIDs make for awfully long IDs and the p:uuid step is optional so > |> I'd be reluctant to make UUID a required scheme for p:label-elements. > |> I'm also reluctant to have some required and some optional schemes. > | > | I understand your point, but since we now have only one XSLT step, I > | don't understand to have to create a new step (even optional) instead > | of simply adding an optional scheme and avoid multiplication of steps > > Now I'm really confused. The p:uuid step generates a UUID and places > it where the user wants it (in an attribute value, in element content, etc.) > It doesn't duplicate the functionality of p:label-elements AFAICS. Ok that's why I ask for a use case (a may be more than one) to explain where we need to generate UUID in an element ? Mohamed -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Wednesday, 28 November 2007 13:10:02 UTC