- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Wed, 20 Dec 2006 08:18:20 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87ejquhfj7.fsf@nwalsh.com>
I don't think I'm ready to spend telcon time on it, but maybe it's
time to start sketching out our defaulting story in email.
Here's a pipeline:
<p:pipeline name="fig1"
xmlns:p="http://www.w3.org/2006/11/pipeline">
<p:input port="source" sequence="no"/>
<p:input port="schemaDoc" sequence="yes"/>
<p:output port="result">
<p:pipe step="s2" port="result"/>
</p:output>
<p:step type="p:xinclude" name="s1">
<p:input port="source">
<p:pipe step="fig1" port="source"/>
</p:input>
</p:step>
<p:step type="p:validate" name="s2">
<p:input port="source">
<p:pipe step="s1" port="result"/>
</p:input>
<p:input port="schema">
<p:pipe step="fig1" port="schemaDoc"/>
</p:input>
</p:step>
</p:pipeline>
If we establish the rule that an unspecified input named "source"
is automatically connected to the output named "result" from the
preceding sibling, then we get:
<p:pipeline name="fig1"
xmlns:p="http://www.w3.org/2006/11/pipeline">
<p:input port="source" sequence="no"/>
<p:input port="schemaDoc" sequence="yes"/>
<p:output port="result">
<p:pipe step="s2" port="result"/>
</p:output>
<p:step type="p:xinclude" name="s1">
<p:input port="source">
<p:pipe step="fig1" port="source"/>
</p:input>
</p:step>
<p:step type="p:validate" name="s2">
<p:input port="schema">
<p:pipe step="fig1" port="schemaDoc"/>
</p:input>
</p:step>
</p:pipeline>
If we extend that rule to include parents for steps that have
no preceding siblings, we get:
<p:pipeline name="fig1"
xmlns:p="http://www.w3.org/2006/11/pipeline">
<p:input port="source" sequence="no"/>
<p:input port="schemaDoc" sequence="yes"/>
<p:output port="result">
<p:pipe step="s2" port="result"/>
</p:output>
<p:step type="p:xinclude" name="s1"/>
<p:step type="p:validate" name="s2">
<p:input port="schema">
<p:pipe step="fig1" port="schemaDoc"/>
</p:input>
</p:step>
</p:pipeline>
If we add the rule that the output named "result" of a component
is automatically attached to the output named "result" from its
last child, we get:
<p:pipeline name="fig1"
xmlns:p="http://www.w3.org/2006/11/pipeline">
<p:input port="source" sequence="no"/>
<p:input port="schemaDoc" sequence="yes"/>
<p:output port="result"/>
<p:step type="p:xinclude" name="s1"/>
<p:step type="p:validate" name="s2">
<p:input port="schema">
<p:pipe step="fig1" port="schemaDoc"/>
</p:input>
</p:step>
</p:pipeline>
And finally, if we say that steps are only optionally named, then
we get:
<p:pipeline xmlns:p="http://www.w3.org/2006/11/pipeline">
<p:input port="source" sequence="no"/>
<p:input port="schemaDoc" sequence="yes"/>
<p:output port="result"/>
<p:step type="p:xinclude"/>
<p:step type="p:validate"/>
<p:input port="schema">
<p:pipe step="fig1" port="schemaDoc"/>
</p:input>
</p:step>
</p:pipeline>
Anyone have more rules in mind?
(I take it as a given that it's an error if you attempt to use the
default rules and they don't apply; for example, if you rely on the
connection to the preceding sibling's 'result' port and it doesn't
have one.)
Be seeing you,
norm
--
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.
Received on Wednesday, 20 December 2006 13:14:13 UTC