Re: Concerns about forwards-compatible mode

Vasil Rangelov <boen.robot@gmail.com> writes:
>>> I suggest that the error be made dynamic instead of static.
>>
>> The WG considered this, but it really isn't practical.
>> Computing the dependency graph for the pipeline is really something
>> that an XProc processor needs to be able to do statically.
>
> OK. Then how about if in forwards compatible mode:
> 1. All input ports in use on p:* steps are added as "valid" ones (or treated
> as being "aliases" to a certain "wildcard" port).
> 2. All input bindings to unknown ports on p:* steps are discarded (or added
> as contents of the wildcard port that doesn't use them for anything).
> 3. All references (by p:pipe) to unknown output ports on in scope p:* steps
> create an empty binding (or cause a dynamic error? If connections between
> steps must also be figured out statically, then I suppose an empty binding
> would be a more appropriate solution).
>
> With these "assumptions", there won't even be a need to contact W3C servers
> to get the new signatures. Signatures are still computed statically - it's
> just that they are far more liberal than in normal mode. Sure, the pipeline
> may produce nonsense if left unchecked, but p:choose is still there to allow
> the pipeline author to write a cross-version pipeline. This approach isn't
> much different than XSLT 1.0's forward compatible mode (which basically says
> "ignore everything unknown").

Imagine that we add a "messages" output port to the p:xslt step in V2.
Then you want to be able to run this step through both V1 and V2
processors:

<p:choose>
  <p:when test="p:system-property('p:version') &lt; 2.0">
    <p:output port="result" primary="true">
      <p:pipe step="xsltv1" port="result"/>
    </p:output>
    <p:output port="secondary">
      <p:pipe step="xsltv1" port="secondary"/>
    </p:output>
    <p:output port="messages"/>
      <p:empty/>
    </p:output>
    <p:xslt name="xsltv1">...</p:xslt>
  </p:when>

  <p:otherwise>
    <p:output port="result" primary="true">
      <p:pipe step="xsltv2" port="result"/>
    </p:output>
    <p:output port="secondary">
      <p:pipe step="xsltv2" port="secondary"/>
    </p:output>
    <p:output port="messages">
      <p:pipe step="xsltv2" port="messages"/>
    </p:output>
    <p:xslt name="xsltv2">...</p:xslt>
  </p:when>
</p:choose>

The V2 processor sees an unbound, non-primary output port so that's
ok.

The V1 processor sees a binding to a non-existant port on p:xslt.
That's a static error.

In order to make that a dynamic error, the processor would have to
mark the step as malformed (so that attempts to run it would always
fail dynamically) but then just accept the binding to a bad port name.

You'd (presumably) only want this in forwards compatible mode, so we'd
have to change the marker. Instead of importing a new library, we
could use a version attribute, I suppose.

This only applies to steps in the p: namespace because those are the
only ones that can be run without an explicit declaration.

Sigh.

What you're proposing is a different and more complex approach. It
requires not only a refactoring of the forwards-compatibility section
but also the introduction of at least one new concept to the language
(the "wildcard" acceptability of unknown port names).

It's entirely possible that the approach you outline could be made to
work, but the WG went a different direction. It's awfully late in the
day to attempt to change this, I fear.

The extent to which this dynamic behavior is important is probably
based partly on how likely one thinks it is that new ports will be
added. I think the WG considers it very unlikely that an existing
step's signature will need to be changed. We could be wrong, of
course.

The XProc design is predicated on the availability of a signature for
each step; it might be possible to reimagine an XProc design which
doesn't have this constraint, but that's not the direction that the WG
went.

>> With respect to new, unknown elements in other contexts (at the top
>> level, in the body of a step, etc.), it's hard to imagine how
>> ignoring them could be the right thing in the context of XProc.
>
> Not ignoring them is fine, as long as it's a dynamic error and not a static
> one and therefore, a p:choose can be wrapped around it, allowing the
> pipeline to execute properly in different XProc versions.

That seems more tractable. Instead of saying that unknown content in a
step is a static error, we could say that it is a dynamic error.
Statically, the content is ignored but it's a dynamic error to attempt
to evaluate that step.

>>From this statement (and the one from the 10 Sep 2009 minutes), it's not
> clear what you mean the resolution for such elements is. Is it a dynamic
> error (please say "yes")?

I think the status quo is "no".

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A man must have grown old and lived
http://nwalsh.com/            | long in order to see how short life
                              | is.-- Schopenhauer