Re: Pipeline Composition and our Recent Pipeline Name/Library Decision

Hi,

Norman Walsh wrote:
> / ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
> | Here's an alternative I could live with: Pipelines are named with
> | expanded names, steps are named with simple names, pipe/@step is an
> | NCName, because that's all you need to refer to another step, and
> | likewise from _inside_ a pipe all you need is its local name.
> 
> I guess that might work, but then we have the weird wrinkle that
> the following pipeline is an error:
> 
>   <p:pipeline name="x:something" xmlns:x="http://www.example.com/ns/pipe">
>     ...
>     <p:xslt name="something"/>
> 
> which seems awkward to explain. (It's an error because you MUST NOT
> have two steps with the same name in the same environment.)

I see two possibilities:

1. Use something similar to the RELAX NG model. The 'name' attribute 
holds the local name only, with a 'ns' or 'namespace' attribute giving 
the namespace for the pipeline:

<p:pipeline name="resolve-and-include"
   ns="http://www.example.com/ns/pipe">
   ...
</p:pipeline>

This syntax encourages, without enforcing, one pipeline library per 
namespace just because it's a pain to have to put ns attributes on every 
<p:pipeline>. [If we went this way, a <p:div> to scope the ns attribute 
would be helpful (and for the ignore-prefixes attribute).]

OR

2. Allow pipelines to be given a local NCName (in the name attribute) 
and a global QName (in an 'export' attribute, for example):

<p:pipeline name="top" export="x:resolve-and-include">
   ...
</p:pipeline>

I kinda like this because I think the names you want to use to refer to 
pipelines from outside (when you use them in other pipelines) are likely 
to be long and descriptive, whereas the names you want to use to refer 
to pipelines from inside are likely to be short and convenient. So 
having two names makes a kind of sense.

Cheers,

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

Received on Wednesday, 21 March 2007 11:24:41 UTC