- From: Innovimax SARL <innovimax@gmail.com>
- Date: Sat, 23 Jun 2007 17:24:38 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
On 6/21/07, Norman Walsh <ndw@nwalsh.com> wrote: > / Innovimax SARL <innovimax@gmail.com> was heard to say: > | In 2.7.1 System Properties > | > | Can we ask that p:episode has to respect NCName production ? > > No. It has to be a QName so that vendors can add extensions in their > own namespace. Oups ! I was talking about the content of p:episode... > > | In 2.7.3 Iteration Count > | > | Could we extend the use of such function to > | * p:insert (to have it for use into the @match) > | * p:label (if we add a @select) > | * p:rename (in @match) > | * p:replace (in @match) > | * p:set-attributes > | * p:string-replace > | * p:unwrap > | * p:wrap > > No. The ordinary position() function works just fine in these contexts. Fair enough ! > I'm not sure I expect atomic steps to be able to evaluate p:* functions. > (They can in my impl, but wouldn't be able to in, for example, Richard's.) Hum...don't like that so I cannot use p:episode in string replace for example ? I'm not sure, I want such limitation > > | In 5.4 p:xpath-context Element > | > | Why p:xpath-context cannot be defaulted to the default readable port ? > > The spec says: > > Only one binding is allowed and it works the same way that bindings > work on a p:input. > > That's supposed to imply that the default binding is the default > readable port, but I can make that more explicit. But right now p:xpath-context cannot have an empty content... > > | @match vs @select > | not sure to understand the limitation for the use of @match instead of > | @select for : > | * p:insert (why a match pattern, if I want to add a title in each nested divs ?) > | * p:rename (why a match pattern, if I want to rename all the divs > | nested or not ?) > > Hmmm. Maybe select makes more sense for insert and rename (and delete, > where it doesn't matter, but I think it should be consistent with > insert and rename)... So what can be the proposal here : Put select everywhere we don't want to allow nesting ? Or do we decorrelate both (@match vs @select / nesting vs non nesting) ? Mohamed -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Saturday, 23 June 2007 15:24:40 UTC