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

Re: Composability

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 07 Jun 2007 21:49:25 +0100
Message-ID: <46686F55.8080509@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Henry S. Thompson wrote:
> Jeni Tennison writes:
> 
>> [Namespaces]
>>
>> The situation that will trip you up, I think, is where the option's
>> value is set based on the value of some attribute or element in a
>> separate XML document.
>>
>> [An increasingly tricky set of examples]
>> I just don't see a way that we can specify how a processor should do
>> this: you need the intelligence of the person writing the pipeline to
>> be able to tell which namespaces need to be used, which means we need:
> 
> Agreed.
> 
>>   (a) a way of passing in namespace bindings to either a step (my
>> preference) or individual options (which I think is too complicated).
> 
> Agreed -- that's what the Markup pipeline language does.  If you
> supply an option whose value is/includes prefixed names, you must
> accompany it with, as it were, <p:bind prefix="..." namespace="..."/>
> 
>>   (b) a way of picking up the namespaces that were in scope when a
>> pipeline was invoked
> 
> I'm not sure I understand, but maybe this means that if you can
> specify option name/value pairs at invociation (e.g. on the command
> line), you need to be able to specify prefix bindings as well, in
> which case I agree.

Yes, you need to be able to set namespace bindings on the command line 
(this is what (a) is about: passing in namespace bindings when a step is 
invoked).

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.

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.

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>

 >>   (c) a way of getting the in-scope namespace declarations within a
 >> pipeline, in order to use those in the set that you then pass into
 >> another step (this can be done with a <p:namespaces> step analogous 
 >> to the <p:parameters> one).
 >
 > I don't see the need for this. . .

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>

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Thursday, 7 June 2007 20:49:31 GMT

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