Re: Concerns about forwards-compatible mode

Vasil Rangelov <boen.robot@gmail.com> writes:

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

Uh huh.

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

I think they will be. Processing a pipeline that contains steps for
which the signatures are unknown is difficult at best and can lead to
ambiguity at worst.

Given 

  <p:foo/>

Does it have a primary input port? A primary output port? 

If <p:foo><p:input port="in"><p:empty/></p:input></p:foo> appears
elsewhere in the pipeline, does that mean that the first p:foo had
two inputs or one?

I appreciate that there's a drawback to requiring 1.0 processors to
read a file from the W3C servers in order to process 2.0 pipelines,
but I don't see a way around it.

>> 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 resolving the ambiguities I described above that concern me.

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

If only you could promise me that it's the last time I'll be 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.

Right. And under the status quo, we can do that, we just have to change
the name of the step, or its namespace.

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

Yes. I understand. I'm trying *very* hard to work out some sort of an
improvement here because *I know* how critical it is to get versioning
right in V1.0.

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

Yep.

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

Right. I'm agreeing with you that that is what you asked for and that I think
that change is practical.

I've floated another couple of proposals in this thread now, a bad one and
maybe a good one.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Reason's last step is the recognition
http://nwalsh.com/            | that there are an infinite number of
                              | things which are beyond it.-- Pascal