Concerns about forwards-compatible mode

I know this is a painful issue, but it's still something that needs to be
crystal clear on all fronts.

"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?

I suggest that the error be made dynamic instead of static. Thanks to that,
pipeline authors will be able to write cross version pipelines with the use
p:system-property(). If the version if high enough, the step will be
executed as normal. If not, and the 1.0 processor attempts to evaluate such
a step, it can fail. Alternatively, it could proceed, but ignore any new
input ports, and not populate any new output ports (i.e. use their default
bindings or an empty binding if no binding is provided). Either way is
better than having a static error on input/output ports.

Personally, I'd prefer the later, as if the newly provided information is
optional, it means the step could be evaluated without it.

For example:
=====
<p:xslt name="transform">
	<p:input port="source">
		<!--Irrelevant-->
	</p:input>
	<p:input port="stylesheet">
		<!--Irrelevant-->
	</p:input>
	<!--In version 2.0, it also outputs a port called "serialization"-->
</p:xslt>
<p:choose>
	<p:when test="p:system-property('p:version') = '2.0'">
		<!--
		Not yet defined fancy way of using the new "serialization"
output port for the pipeline's serialization options.
		The following is just one possible way of declaring it,
perhaps in version 2.0.
		-->
		<p:serialization port="result">
			<p:input port="parameters">
				<p:pipe step="transform"
port="serialization" />
			</p:input>
		</p:serialization>
	</p:when>
	<p:otherwise>
		<!--Request serialization with the default serialization
parameters if the processor version is 1.0-->
		<p:serialization port="result" />
	</p:otherwise>
</p:choose>
=====

The spec could also prohibit the addition of new input/output ports with no
default bindings* and make THAT a static error.

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.

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? Will 1.0 processors be forced to go to it if XProc
2.0 arises (to get the new declarations)? 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.

* 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? Does the step receive an empty binding (but could still output
something), or does it automatically fail? Neither seems to be in the spec,
or perhaps I've missed it.

Regards,
Vasil Rangelov

Received on Saturday, 5 September 2009 10:33:54 UTC