W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > June 2007

Re: New draft...sortof

From: Innovimax SARL <innovimax@gmail.com>
Date: Sat, 23 Jun 2007 17:24:38 +0200
Message-ID: <546c6c1c0706230824g8449821l22a27adedbb033f8@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT