RE: Concerns about forwards-compatible mode

> 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.

This is basically an outline of the problem I'm worried about. BTW, that
messages port sounds like a great idea. I think I realize why it's not in V1
(hard to implement for some XSLT processors?), but it does sound like
something really useful and something to seriously consider for V2... and it
is the best example yet as to why some existing steps may need to add new
input/output ports in the future.

> Instead of importing a new library, we could use a version attribute, I
suppose.

The exact version notation is somewhat irrelevant I think. The problem is in
the behavior when in forwards compatible mode... it's currently too limiting
(in general). As long as V1 processors aren't forced to download signatures
of steps by contacting W3C servers, the current notation would be fine.

> 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).

Is it THAT hard to specify it? Since it applies only to p:* steps while in
forwards compatible mode, it seems to me like a single (or at worst - a few)
extra paragraph(s) at "2.13 Versioning Considerations" will pretty much
cover it. A note or something at p:import may also be necessary, and that's
all. I don't see what else (at other parts of the spec) that would need
changing.

> 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.

I'm sorry I'll have to put it in this way, but... You ARE wrong. Your own
example is good enough (and like I said, a great) use case showing that
future ports may be needed for existing standard steps, p:xslt being the
most likely candidate for such. One other example (again, if your own isn't
enough) is the use of a serialization input port instead of serialization
options to all steps that perform serialization (p:store, p:escape-markup,
etc.) or a serialization output port to all steps that may control
serialization if used stand alone (p:xslt, etc.).

But perhaps the best example is if a future version of an external
specification needs accommodation that can be achieved simply by the
addition of a few optional ports (and perhaps with a few new options, which
would be ignored by XProc 1.0 anyway). Again, p:xslt serves as the best
example. The "secondary" port is useless for a standard XSLT 1.0, but if
XProc was created before XSLT 2.0, it would have had to create p:xslt2 (as
was once the case...). If XQuery makes a similar addition, the spec
currently forces future versions of XProc to create p:xquery2 (assuming it's
XQuery 2 that has this change). As seen already in the debate at the times
of p:xslt and p:xslt2, hard coding the version in the type isn't entirely a
good idea, as it will quickly become outdated as newer versions of the
external spec (with no need for a new signature) arises, it creates clutter,
creates inconsistencies if only the "changed" versions are accommodated
(p:xquery and p:xquery3, but no p:xquery2) and it simply feels too dirty.

Even if V1 standard steps didn't needed to be extensible port wise, some of
the steps in V3 may need to extend steps that first appeared in V2. Due to
V1's limitation, they won't be able to do that, unless they sacrifice V1
support, or (as. Depending on the time frame between V1, V2 and V3, and the
number of implementations on each, sacrificing V1 may or may not be a good
design choice at the point of V3.

If by "awfully late" you mean that this change would have to push the spec
back to (LC?)WD... since this is a V1 of a language, if there's any issue
that is worthy enough to push it back to this state, I think forwards
compatibility is the one. V1 (of any language, especially one like XProc)
just can't afford to get this wrong.

> 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.

Uh... well, yes... this is exactly what I'd like... and I think this is what
I said... if not, know that this is what I meant when I say "dynamic error"
(I assume static checks happen before p:when evaluation, and therefore if
something is a static error, it occurs with or without p:when; I also assume
non-static checks are dynamic checks). Yes, please do that.

Regards,
Vasil Rangelov

-----Original Message-----
From: public-xml-processing-model-comments-request@w3.org
[mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of
Norman Walsh
Sent: Wednesday, October 07, 2009 3:24 PM
To: public-xml-processing-model-comments@w3.org
Subject: 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

Received on Wednesday, 7 October 2009 21:12:41 UTC