Re: New draft...sortof

On 6/24/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / Innovimax SARL <innovimax@gmail.com> was heard to say:
> | 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...
>
> The content? It's used like this:
>
>   p:system-property("p:episode")
>
> I'm not sure what content you mean.

I was talking about the type of p:system-property("p:episode"), beside
the fact that it is a string. Do me mandate, that it is NCName ? or
any kind of string ?



>
> |> 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
>
> You can always let the processor do the evaluation:
>
>   <p:string-replace>
>     <p:option name="match" value="TEMPID"/>
>     <p:option name="replace" select="concat('foo-', p:system-property('p:episode'))"/>
>   </p:string-replace>

Ok, I see, but still not sure we can handle all use cases that way
Sadly, I  have none in mind at this time, will try to make some
samples clear not too far from now.

>
> |> | 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...
>
> Oh, sorry. I think that's just an oversight. Fixed.

Ok

>
> |> | @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) ?
>
> I'm not sure.
>
Seems like this point needs some telcon to be worked out

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 Sunday, 24 June 2007 21:32:24 UTC