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