Re: New draft...sortof

/ 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'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>

|> | 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.

|> | @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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | We learn from experience that not
http://nwalsh.com/            | everything which is incredible is
                              | untrue.--Cardinal De Retz