Re: Another take on versioning

First stop, wow! It has been a long time since I last saw a discussion as
"intense" as this one. Lots of different ideas floating around. Here's my
thoughts on some of the issues raised:

1. Version attribute required or not - currently the spec says that
specifying the version is not required and the implied version is the latest
one supported by the processor. I think this is a good thing. If you want to
quickly develop a pipeline that works in your current environment, you just
do it without worrying for the version. If you want to write a portable
pipeline, you'll specify the latest version supported, so that older
versions go into forwards compatible mode instead of (potentially?) failing
with a static error. Required or not, I'm sure it will be preached in all
tutorials as being a good practice, and therefore a thing that pipeline
authors will do anyway, with or without it being required.

2. Treatment of unknown steps

I think this is a wrong way to think about it (the word "steps" I mean).
There are some elements that don't have a formal qualification. They aren't
"atomic steps", they aren't "contained steps", they aren't (always) direct
child elements of steps either. They need a formal qualification, and
unknown elements (regardless of their formal qualification in future
versions) should be treated as these kinds of elements would be treated.
These elements currently include (among others?) p:declare-step, p:pieline,
p:import, p:log, p:serialization, p:xpath-context, p:iteration-source,
p:viewport-source, p:inline, p:document, p:pipe, p:empty, p:input and
p:output. I suggest a name like "instructions" or something similar. The
exact name is irrelevant, as long as it exists, and is defined as "all other
elements" (extra qualifications, such as "top level elements" are also
acceptable, but "all other elements" is a must). In forwards compatible
mode, if an unknown element is encountered, it is treated as an unknown
"instruction". If an unknown "instruction" is evaluated, it results in a
dynamic error. I mean, think about it.
How is <p:xyz/> within <p:pipeline/> different from <p:serialization/> OR a
step (atomic or contained) at the same place?
How is <p:xyz/> within <p:when> different from <p:xpath-context/> OR a step
(atomic or contained) at the same place?
How is <p:xyz/> within an atomic step different from <p:output/> on this
same step?
How is <p:xyz/> within <p:input/> different from <p:document/> on this same
context?

The answer is it's not any different. "Instructions" can appear anywhere,
and therefore, unknown elements (with or without having child elements that
make them look like steps) can be treated as "instructions".

3. Treatment of existing steps with altered signatures

This is the only real issue. The spec currently forces connections between
steps to be determined statically with or without forwards compatible mode.
This creates a problem. As already said by Norman Walsh "The XProc design is
predicated on the availability of a signature for each step". I realize the
blind removal of this constrain is going to make the spec much more
difficult to implement.

Like Toman Vojtech, I'm not sure what does "correct" really mean.

What should a processor do when an unknown output port is "correctly"
referenced? I suggest that in forwards compatible mode:

"If a connection is made to an output port which is not known to the
processor (for example, an attempt to connect to the "xyz" output port of
the p:identity step), an empty sequence of documents (as defined by p:empty)
must be provided."

I say "as defined by p:empty", so that the connection could still be
resolved statically (as being equivalent to having <p:empty/> instead of
<p:pipe/> at that spot). Again, I realize a dynamic error for this is a "no
no".

The treatment of unknown input ports should also be explicitly addressed
(separately) with something like:

"If a connection is made at an input port which is not known to the
processor, the processor must ignore the input port and behave as if the
step was executed without it."

4. Backwards-compatible Mode

I think forcing future specifications to adhere to this is going a step too
far. V2 is likely to create a new section like this anyway. One that would
be "compatible" with whatever design changes occur at that point, and one
that may cause some "known issues" when running V2 as V1. See XSLT 2.0 for
example. Same MAY apply for V3 as well. Since V1 is (by definition) the
first version, it doesn't need to specify a backwards compatible mode.

5. Miscellaneous

Right before I was about to hit "Send", I saw that altered version, and from
a first glance... since this still forces processors to contact W3C servers
to get the new signatures, this seems far from a complete solution. A good
first step though. Note that with the kind of proposals outlined above, this
need should be eliminated completely.

Regards,
Vasil Rangelov

Received on Friday, 9 October 2009 20:36:10 UTC