Re: Simplification of proposal for subordinate source elements

Hi,

Murray Maloney wrote:
> Here's a sub-proposal to rename and consolidate. The <p:pipe/> was 
> offered by Richard
> as an alternative for <p:internal/>. I really like the name because it 
> fits into and supports
> the pipeline metaphor so readily. I realized why I objected to 
> <p:document/> for <p:here/>
> and I decided to consolidate <p:external/> with <p:here/> to garner a 
> simple <p:document/>
> that encompasses both into a single element. The distinction that we are 
> left with is between
> pipes and documents. No need to simplify any further.

I really like these names, and the consolidation of <p:external> and 
<p:here> into <p:document>.

> Consider...
> 
> <p:input port="myInput" select="..." sequence="no">
>         <p:pipe step="step1" port="result" />
>         <p:document href="http://www.muzmo.com/.../document.xml"/>
>         <p:document><p>Document is right here.</p></p:document>
> </p:input>
> 
> <p:output port="myOutput" select="..." >
>         <p:pipe step="step8" port="result" />
>         <p:document href="http://www.muzmo.com/.../document.xml"/>
>         <p:document><p>Document is right here.</p></p:document>
> </p:output >

It's not clear to me in these examples how the multiple documents are 
meant to be interpreted. What I'd suggest is that sibling <p:pipe> and 
<p:document> elements are used to construct a sequence of documents; 
*nested* <p:pipe> and <p:document> elements are used to provide 
alternatives in case documents can't be loaded.

So:

   <p:input name="schemas" sequence="yes">
     <p:pipe step="construct-schema" port="result" />
     <p:document href="xlink.xsd" />
     <p:document href="xml.xsd" />
     <p:document>
       <xsd:schema>...</xsd:schema>
     </p:document>
   </p:input>

is used to provide a sequence of documents to the 'schemas' input, with 
the first generated by the 'construct-schema' step, the second and third 
from the external documents 'xlink.xsd' and 'xml.xsd', and the final one 
a here document.

> Default <p:pipe/> attribute values are step="previous" or step="next" 
> depending on
> whether the active context is <input> or <output>. The default is always 
> port="result."

I assume that the step attribute doesn't actually recognise keywords, 
and that you mean it defaults to the name of the previous step (on 
<p:input>). I think that the default of the step attribute on <p:output> 
should be the *last* step in the subpipeline.

I'm undecided about whether we should be forcing people to use the name 
'result' on their output ports if they want to use defaulting; an 
alternative would be for the port to always default to the only output 
of the step (and it be an error if there's more than one).

> I have always appreciated the power inherent in co-constraints between 
> content
> and a privileged attribute, especially when one of them is (or implies) 
> a link.
> 
> In the case that both href value and content are provided on <p:document>
> the href value has precedence by default, but it is not an error to 
> provide both.
> 
> <p:input port="myInput" select="..." sequence="no">
>     <p:document href="http://www.muzmo.com/.../document.xml">  <!-- has 
> precedence -->
>        <p>Document is right here.</p> <!-- ignored -->
>     </p:document>
> </p:input>

I agree that's nice. I think, though, that the content of <p:document> 
should be another <p:document>, so that you can have multiple access 
paths to the same document, e.g.:

   <p:input name="preferences" sequence="no">
     <p:document href="user.xml">
       <p:document href="group.xml">
         <p:document href="system.xml">
           <p:document>
             <prefs>...</prefs>
           </p:document>
         </p:document>
       </p:document>
     </p:document>
   </p:input>

giving priority to user preferences if they exist, then group-level 
preferences, then system-wide preferences, and finally the built-in 
preferences.

You could also imagine <p:pipe> being nested within <p:document> to 
provide a generated default; I don't know if that's going too far and 
would lead to complications because you wouldn't know at compile time 
whether the document existed or not (and therefore whether a particular 
sequence of steps should be executed).

Cheers,

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

Received on Friday, 8 December 2006 09:37:39 UTC