- From: <Toman_Vojtech@emc.com>
- Date: Fri, 31 Oct 2008 04:57:45 -0400
- 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 step... -- 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? Regards, Vojtech (Sorry for the long e-mail.)
Received on Friday, 31 October 2008 09:07:42 UTC