- 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