RE: A (hopefully comprehensive) versioning proposal

Norm,

many thanks for spending your time on this. See below for my
comments/remarks.


> ============================================================
> 
> Proposal 1: Add a version attribute.
> 
> The version attribute is allowed on any element. On an element in the
> XProc namespace, it is "version" in no namespace. On an element not in
> the XProc namespace, it is "p:version" in the XProc namespace.

Are you suggesting we could use p:version on, for instance, c:data,
c:directory or c:request?
I can probably see what you were aiming at (we may decide to add new
elements to the c:request model in Vnext), but I don't really see how
this can work in practice. It seems to me you would have to add some
intelligence to steps that consume (and probably produce?) documents in
the xproc-step namespace, so that they can filter them based on
p:version.

Personally, I wouldn't support "p:version" on non-XProc elements. I
would just say that you have to use "p:use-when" in this case.

> ============================================================
>
> Proposal 2: The version attribute is required on top-level
> p:pipeline, p:declare-step, and p:library elements.

+1 from me. Just a question: At the moment, we allow explicitly
importing a standard XProc library using p:import. With the "version"
attribute, shouldn't we make this forbidden? Because with the "version"
attribute and the defaulting rules, the processor would always know what
to do.

> ============================================================
> 
> Proposal 3: Add a use-when attribute
> 
> The use-when attribute is allowed on any element. On an element in the
> XProc namespace, it is "use-when" in no namespace. On an 
> element not in
> the XProc namespace, it is "p:use-when" in the XProc namespace.

+1

So, if you wan't to preserve p:use-when elements in your XML documents,
you would either have to escape/unescape the documents (p:escape-markup,
p:unescape-markup), or make them external, right?

> ============================================================
> 
> Proposal 3: Attempt to treate unknown XProc step types as 
> dynamic errors
> 
> Pipelines that attempt to unconditionally evaluate unknown step types
> are guaranteed to fail. It's possible that some new XProc steps may
> have attributes or children that a previous processor could not be
> expected to interpret.
> 
> In order to minimize the disruption such elements cause, while at the
> same time making it as easy as possible to write pipelines that will
> run in fowards-compatible mode on an earlier processor, we adopt the
> following rules:
> 
> In forwards-compatible mode:
> 
> Steps in the XProc namespace which the processor does not recognize
> are marked invalid. It is a dynamic error (err:XD00??) to attempt to
> evaluate a step that is marked invalid.
> 
> Any subpipeline that directly contains a step which has been marked
> invalid is also invalid.
> 
> If a p:when directly contains an unknown XProc step type, that entire
> branch is marked invalid. No static analysis is performed on the steps
> within that pipeline. It is a dynamic error (err:XD00??) if that
> branch of the p:choose is selected at runtime.

I think you *MUST* statically check the pipe bindings in the branch; not
doing so may break the dependency graph. The steps in the when- or
otherwise- branch may contain dependencies on steps outside p:choose,
and not statically checking the branch may result in the p:choose being
executed before the steps it actually depends on!

> 
> If a p:group inside a p:try directly contains an unknown XProc step
> type, that group is marked invalid. No static analysis is performed on
> the steps within that group. An attempt to evaluate the p:try will
> immediately evaluate the p:catch with an empty errors port.

Again, I think the same as with p:choose applies here and you MUST do
some sort of static analysis in p:group in p:try and p:catch.

> If all of the branches of a p:choose or p:try are invalid, the
> p:choose or p:try is treated as if it had no primary output port.

Why?


> ============================================================
> 
> Proposal 4: Support binding defaults in forwards-compatible mode
> 
> In forwards-compatible mode:
> 
> It is not a static error to encounter an unknown XProc step type. Such
> steps are assumed to have no primary input ports, no primary output
> ports, and no parameter input ports. It is a static error if, under
> these assumptions, a valid dependency graph cannot be constructed.
> 
> It is not a static error to encounter explicit bindings to unknown
> ports on an XProc step type. Such bindings are assumed to be correct.
> Dynamically, a step must ignore all inputs that appear on an unknown
> input port and must produce an empty sequence of documents on unknown
> output ports.

+1


> ============================================================

> E. Dynamic errors 1
> 
> The following pipeline is statically valid to an XProc 1.0 processor
> and will run without errors.
> 
>   <p:pipeline version="2.0">
> 
>     <p:choose>
>       <p:when test="system-property('p:version') &gt; 1.0">
>         <p:fribble/>
>         <p:sink/>
>       </p:when>
>       <p:otherwise>
>         <p:identity/>
>       </p:otherwise>
>     </p:choose>
> 
>   </pipeline>

> 
> The first p:when branch is marked invalid because it contains the
> unknown (from the 1.0 perspective) step p:fribble. As a result, no
> static analysis is performed on that subpipeline

Again, I think you have to check the pipe bindings in the branch

> and that subpipeline
> does not contribute to the constraint that all the branches of a
> p:choose must declare the same outputs.

Hmm. Even if the when branch explicitly declared the outputs, or if the
last step of the subpipeline is a known step?

 
> K. Static errors 2
> 
> This pipeline is statically *in*valid:
> 
>   <p:pipeline version="2.0">
>     <p:choose>
>       <p:when test="system-property('p:version') &gt; 1.0">
>         <p:unknown/>
>       </p:when>
>       <p:otherwise>
>         <p:unknown/>
>       </p:otherwise>
>     </p:choose>
>   </p:pipeline>
> 
> There's nothing for the p:output on the p:pipeline to bind to by
> default.

Because all branches of p:choose are invalid and they don't participate
in the test that all branches have the same output signature - and
therefore the p:choose has no output ports, right?
 
 
> I haven't attempted to propose what a 1.0 processor should do if the
> 2.0 step declarations are loaded and they differ from what it expected
> in 1.0.

I mentioned that earlier, but is there still any point in supporting
importing standard XProc step declarations if we introduce the required
"version" attribute?

Regards,
Vojtech

Received on Friday, 16 October 2009 10:34:56 UTC