W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > December 2006

The defaulting story

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:49 GMT