Re: Composability

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Jeni Tennison writes:
|> Henry S. Thompson wrote:
|>> Jeni Tennison writes:
[...]
|> But if you're within the invoked pipeline, you need a way of knowing
|> what those namespace bindings were and of passing them on through to
|> any steps within the pipeline. Here's an example.
|>
|> On my command line, I do:
|>
|>> myproc mypipe.xpl -in source="*.xml"
|>                     -opt test="/e:foo/e:bar = 'baz'"
|>                     -ns e="http://www.example.com/ns/example"
|>
|> My pipeline looks like:
|>
|> <p:pipeline xmlns:p="...">
|>   <p:input port="source" sequence="yes" />
|>   <p:output port="result" sequence="yes" />
|>   <p:option name="test" required="yes" />
|>   <p:split-sequence>
|>     <p:option name="test" select="$test" />
|>   </p:split-sequence>
|> </p:pipeline>
|>
|> The namespace binding for the 'e' prefix gets passed into my
|> pipeline. Fine. But what namespace bindings get passed into the
|> <p:split-sequence> step? I think that the answer is that only the
|> namespace bindings that are in-scope on the <p:split-sequence> element
|> get passed to that step. The only namespace binding that's in scope
|> within the pipeline is the XProc namespace. So there's no binding for
|> the 'e' prefix, and the step fails.
|
| That's where what Norm and I discussed before will do the job -- if
| you have an option to a step (in this case the pipeline itself) which
| is accompanied by explicit NS bindings, it carries those bindings with
| it forever.

No, Jeni's analysis is consistent with what I had in mind. The
p:option element is something I can hang namespace bindings on. Maybe
I can jiggle things so that they're associated with the String and
consequently with the command line argument, but that wasn't my
immeiate intention.

|> Worse, if I have:
|>
|> <p:pipeline xmlns:p="..."
|>             xmlns:e="http://www.example.com/ns/some/other/namespace">
|>   <p:input port="source" sequence="yes" />
|>   <p:output port="result" sequence="yes" />
|>   <p:option name="test" required="yes" />
|>   <p:split-sequence>
|>     <p:option name="test" select="$test" />
|>   </p:split-sequence>
|>   ...
|> </p:pipeline>
|>
|> then the 'e' prefix is bound OK, but to the wrong namespace! I won't
|> even get an error, just fail to get the result I should.
|
| See above -- on my account (and I think Norm's) you don't _ever_ get
| the in-scope NS bindings from the pipeline doc't infoset, you only get
| the explicit ones bound _using_ the pipeline language.

Huh? I don't follow that. You most certainly get NS bindings from the
pipeline doc't infoset. That's how this works:

  <p:step xmlns:f="...">
    <p:option name="match" value="/e:foo/f:bar"
              xmlns:e="..."/>
    ...

Again, I agree with Jeni's analysis on this one.

| Note this has all been about XPaths evaluated _by a component_, and my
| initial assumption is that for XPaths evaluated _by the engine_, the
| in-scope bindings from the infoset _will_ be used.  I agree this will
| cause some confusion, maybe the right answer is to always include the
| in-scope implicit bindings along with the in-scope explicit bindings,
| but give the latter precedence over the former. . .

What the heck is the difference between the in-scope explicit bindings
and the in-scope implicit ones?

|> What I want is to take the in-scope namespaces from the invocation of
|> the pipeline and pass *them* through to the steps in the pipeline.
|>
|> For example, analogously to parameter sets:
|>
|> <p:pipeline name="pipe"
|>             xmlns:p="..."
|>             xmlns:e="http://www.example.com/ns/some/other/namespace">
|>   <p:input port="source" sequence="yes" />
|>   <p:output port="result" sequence="yes" />
|>   <p:option name="test" required="yes" />
|>   <p:split-sequence>
|>     <p:option name="test" select="$test" />
|>     <p:namespace-bindings>
|>       <p:pipe step="pipeline-namespaces" port="result" />
|>     </p:namespace-bindings>
|>   </p:split-sequence>
|>   <p:namespaces name="pipeline-namespaces" />
|>   ...
|> </p:pipeline>
|
| Much too much mechanism for a corner case of a corner case, in my view.

That's the question, I think.

Are we going to invent and describe the mechanisms necessary to
support loading XPath expressions from the command line (or from
external configuration files) or are we going to say that those use
cases can only be solved in very limited circumstances in V1.

|> You're right, as long as there's a way of binding individual
|> namespaces explicitly (like your <p:bind> element). After all, if
|> you're in the pipeline then you know already what namespaces are in
|> scope and you can just copy the ones you need. For example:
|>
|>   <p:split-sequence>
|>     <p:option name="test" select="concat('/f:wrap', $test)" />
|>     <p:namespace-bindings>
|>       <p:pipe step="pipeline-namespaces" port="result" />
|>       <p:namespace prefix="f" uri="http://www.example.com/ns/f" />
|>     </p:namespace-bindings>
|>   </p:split-sequence>
|
| I'd much prefer to just have
|
|   <p:split-sequence>
|     <p:option name="test" select="concat('/f:wrap', $test)" />
|     <p:bind prefix="f" uri="http://www.example.com/ns/f" />
|   </p:split-sequence>

We don't need p:bind unless we want to solve Jeni's use case and if we
want to solve it, p:bind as you've described is insufficient. Just
like parameter-sets need access to files and command line params, this
mechanism would need access to files and command line namespace
bindings.

| Note that as far as I can see both your _and_ my approaches will do
| 'the wrong thing' in the following case:
|
|    > myproc mypipe.xpl -in source="*.xml"
|                     -opt test="/e:foo/e:bar = 'baz'"
|                     -ns e="http://www.example.com/ns/e1"
|
|       <p:split-sequence>
|         <p:option name="test" select="concat('/e:wrap', $test)" />
|         <p:bind prefix="f" uri="http://www.example.com/ns/e2" />
|       </p:split-sequence>
|
| _Caveat scriptor_.

Yeah, that one's just unsolvable.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is a general error to imagine the
http://nwalsh.com/            | loudest complainers for the public to
                              | be the most anxious for its
                              | welfare.--Edmund Burke, 1769