W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2008

Possible problems with unsupported steps

From: <Toman_Vojtech@emc.com>
Date: Fri, 31 Oct 2008 04:57:45 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870D404F04@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>

Hi all,

The spec says that the XProc processor should not statically reject
pipelines (or libraries) that refer to steps which the processor does
not support - unless, of course, the processor can detect upfront that
some of these steps will get executed and the pipeline would therefore
fail (but detecting that is usually hard or just impossible). So, in
most cases, the processor will try to run the pipeline and fail with
XD0017 if it encounters an unsupported step.

So far so good. But the thing about unsupported steps is that the
processor not only does not support them, but it also does not know
their declarations - which, among other things, means that it doesn't
know what the step's input and output ports are (and which of them, if
any, are primary). This can cause problems when the processor processes
the pipeline document, establishes the running order of steps and
detects static errors.

The XProc processor has to guess the declarations of the unsupported
steps, which is... not very nice, I must say. In most cases, the
processor will probably try to do its best to make sure that the
pipeline at least executes - based on the context (looking at the way
the step is invoked; using the references from other steps; ...) and in
order to avoid static errors, the processor can assume that the step has
a number of input and output ports with certain properties, these and
these options, etc.

But the guess can be wrong. Also, whether the XProc processor does the
guess at all (and how) is completely implementation-defined, which may
cause annoying problems. Suppose we have two XProc processors: A which
supports x:unsupported-step, and B which does not. Then the following
can happen:

- B accepts a pipeline that A would reject because of static errors.
Here, B guesses some properties of ex:unsupported-step that are not in
the step's declaration.

- Both A and B accept the pipeline, but B executes the steps in
different order. This can happen, for instance, if B manufactures a
primary input port for ex:unsupported-step, but the step declaration
specifies no input port at all. Because of the artificial input port,
the step will be then connected to the primary output port of some other


I may be just too immersed in the implementation side of things, so I
may be seeing things worse than they are. But to me, it seems that
"support" for unsupported steps can lead to some interoperability issues
unless the specification states what the XProc processor should do when
it encounters an unsupported step during the *parsing/compilation*
phase. Perhaps the spec could contain a non-normative section with a
(deterministic) algorithm that would describe the "guesses" the XProc
processor can/must make so that the pipeline at least executes.

Any thoughts about this?


(Sorry for the long e-mail.)
Received on Friday, 31 October 2008 09:07:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:08 UTC