RE: Concerns about forwards-compatible mode

> Yes. At the moment, that is what will be required. Though I think it's
> more likely that this would be accomplished by changing the namespace
> of the p:xslt step than adding new local names.

That option isn't much better than adding a new step in the same namespace.
It may be easier to implement, but regardless, it will be messier. Besides,
XSLT and most other W3C specs don't change their namespace from version to
version (even if only for new elements). Why should XProc be any special in
that regard?

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

The only burden that future versions of the spec carry is that they must not
add an input port to an existing step without specifying a default binding
for it, as doing otherwise is going to cause a static error on their own
version, while making nonsense on version 1.0 (i.e. they'd create a
regression).

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

>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")?

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: Thursday, October 01, 2009 11:58 PM
To: public-xml-processing-model-comments@w3.org
Subject: Re: Concerns about forwards-compatible mode

Vasil Rangelov <boen.robot@gmail.com> writes:
> I know this is a painful issue, but it's still something that needs to 
> be crystal clear on all fronts.

It is. Thanks for taking the time to try to improve the clarity.

> "2.13 Versioning Considerations" says about forwards-compatible mode, 
> ===== 3. It is a static error if the signature of a known step in the 
> version library has changed, except for new options.
> 4. New options on known steps are ignored in the pipeline.
> As a consequence, future specifications must not change the semantics 
> of existing step types without changing their names.
> =====
>
> What happens if future versions need to only add a certain 
> input/output port for additional information that would otherwise be 
> optional? For example, I once suggested that there is a 
> "serialization" output port on the p:xslt step that will expose the 
> serialization options that XSLT would have used for the primary 
> document if it could serialize it. The suggestion was declined, but 
> suppose that a future version wanted to add it... will it have to make
p:xslt-plus-serialization? What about if something else pops along?
> A new name like p:xslt-plus-serialization-plus-whatever?

Yes. At the moment, that is what will be required. Though I think it's more
likely that this would be accomplished by changing the namespace of the
p:xslt step than adding new local names.

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

> Also, what happens if certain now known elements have unknown child 
> elements (as in the example above with p:serialization)? I think in 
> forwards-compatible mode, the processor should skip such child 
> elements (as if they don't exist), or fail with a certain dynamic 
> error (not static; see above example). If not in forwards-compatible 
> mode, such unknown child elements could be treated as a static error.

p:serialization has no child elements, only attributes. We could try to be
more liberal about unknown attributes, but it's not clear how valuable this
would be.

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.

> Last, but not least, how should the processor make a difference 
> between an XProc standard library and an erroneous custom library 
> import? That is, if I have a library that declares (but doesn't 
> implement) a step in the XProc namespace, this is an error by the spec 
> (which is perfectly fine). How will the processor know I am not 
> instead importing the XProc 2.0 standard library (or a copy of it)? 
> Will the "http://www.w3.org/" domain be explicitly white listed for this
purpose?

More than the domain. If the absolute URI of an imported library conforms to
the regex: "http://www.w3.org/[0-9][0-9][0-9][0-9]/xproc-.*" then it is
recognized as a new standard library and may declare steps in the XProc
namespace (consistent with the other requirements on forwards-compatible
behavior).

This is described in 5.10, p:import.

> Will 1.0 processors be forced to go to it if XProc 2.0 arises (to get 
> the new declarations)?

They won't be forced to, but if you want to write a pipeline that a 1.0
processor can process in forwards-compatible mode, you will have to
explicitly import the 2.0 standard library.

> If so, this sounds ridiculous to
> me. Even XHTML doesn't require implementers to be validating against 
> its DTD, and therefore doesn't require implementations to contact W3C
servers.
> XProc shouldn't be any different - XProc 1.0 processors should be able 
> to proceed in forwards-compatible mode without contacting W3C servers.

Perhaps. Though I can't think of any possible way to do that.

> * I'm guessing that is what makes a port required. Speaking of which 
> (not directly related to forward compatibility), what happens if a 
> non-primary input port is missing upon step call and doesn't have a 
> default binding declared?

That's a static error, err:XS0003.

The WG considered your suggested improvements during the 10 Sep 2009 telcon
but resolved not to make any changes. If you are unsatisfied with this
resolution, please let us know.

                                        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 Sunday, 4 October 2009 19:45:30 UTC