Re: p:pipeline

Rui Lopes wrote:
> Jeni Tennison wrote:
>> I don't understand (I said no nested pipelines). If someone has a
>> pipeline document at foobar.xp like:
>>
>> <p:pipelines xmlns:p="...">
>>   <p:pipeline name="foo">
>>     ...
>>   </p:pipeline>
>>   <p:pipeline name="bar">
>>     ...
>>   </p:pipeline>
>> </p:pipelines>
>>
>> then you can use either the 'foo' or 'bar' pipeline by including
>> foobar.xp into your pipeline document, and referencing them in a step:
>>
>> <p:pipelines xmlns:p="...">
>>   <p:import href="foobar.xp" />
>>   <p:pipeline name="baz">
>>     ...
>>     <p:step kind="foo">...</p:step>
>>     <p:step kind="bar">...</p:step>
>>     ...
>>   </p:pipeline>
>> </p:pipelines>
> 
> I tend to like this approach, but I belive that most of the times users 
> won't need to define multiple pipelines in the same file. It might be a 
> 15% case, probably. For the other cases (85%), the user shouldn't need 
> to type extra tags (i.e. <p:pipelines>). And this feature would require 
> for us to define which pipeline was triggered automatically (like 
> makefile's and ant's target "all"). Do we really need to cope with these 
> issues to ease a 15%-case? I'm not sure.

I think it's unreasonable to require that every invokable pipeline 
definition should be in a separate file. If we want several invokable 
pipeline definitions in a single file, we need to have a wrapper for 
them. I'm not saying that every XProc document should have a 
<p:pipelines> wrapper, just that it needs to be a possibility.

You seem to be making the assumption that a user should be able to 
invoke a pipeline by simply pointing at an XProc document. I'm making 
the assumption that a user invokes a pipeline by supplying a *QName* and 
  (any number of) XProc documents.

My opinion is that you will *usually* want to have multiple pipelines 
defined in a single file, for modularity and reusability. I'm imagining 
creating pipeline documents like:

<p:pipelines>
   <p:pipeline name="test:generate-test-xsl">
     ...
   </p:pipeline>

   <p:pipeline name="test:run-test-xsl">
     ...
     <p:step kind="test:generate-test-xsl">...</p:step>
     ...
   </p:pipeline>

   <p:pipeline name="test:format-test-result.xsl">
     ...
   </p:pipeline>
</p:pipelines>

that enable users to do several processes at once, or one at a time, 
depending on their needs at the time.

>> As I said in my previous mail, I don't (at the moment) see the
>> requirement for pipelines that are local to other pipelines. Why not
>> have *only* 'global' pipelines? (Analogy with XSLT: we don't let people
>> define templates inside other templates or functions inside other
>> functions.)
> 
> I believe local pipelines are analog to XSLT's named templates and 
> functions, as these may be called inside other templates.

These may be *called* from within other templates, but they can't be 
*defined* within other templates. Putting <p:pipeline> within 
<p:pipeline> is like defining a template within another template. Using 
<p:step> to invoke another pipeline from within a pipeline is like 
calling a template within another template.

>> If we do have a language for declaring non-pipeline components, we're
>> going to have to address issues such as:
>>
>>  - providing mechanisms for pointing to definitions in different
>>    programming languages, including handling things like classpaths
>>
>>  - dealing with situations where different definitions are provided in
>>    different programming languages, and enabling the implementation to
>>    choose between them
>>
>> This could get quite sticky... Perhaps the fact that you used an
>> extension attribute (my:javaClass) indicates that you think only the
>> basics should be part of XProc, and the rest implementation-defined?
> 
> If we allow implementation-specific issues to be configured in this type 
> of files, maybe we should leave it outside the scope of xproc.

I'm somewhat equivocal. There's an advantage in having 
<p:declare-component> as part of XProc in that it means *any* XProc 
processor (or indeed XML editor) can check that the XProc document 
itself is constructed correctly (calls each component with the correctly 
named inputs and outputs). It's then an error if an implementation 
either doesn't support that component (doesn't have a definition for it) 
or has a different signature for the component than that given in the 
XProc file.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 24 July 2006 13:53:35 UTC