Comments from the XSLT WG on the XProc Last Call Document

To: XML Processing Model WG:

From: XSLT WG

Subject: XSLT Comments on XProc: An XML Pipeline Language  -
http://www.w3.org/TR/xproc/

The XSLT WG has agreed that the following comments represent the position
of the WG on the XProc: An XML Pipeline Language Last Call document.

1. In using full XPath 1.0 (or 2.0) the XProc specification has some of 
the
same problems with large documents regarding streaming as we have seen 
with
with XSLT.  Streaming is an important use case for XML processing in
general and in specific any pipeline language should make some provision
for streamability.  We also suggest that you consider adding an 
indication for each step specifying whether the step is streamable or not.

2. The "Required Steps" in the "Standard Step Library" includes a large
number of specific tasks that typically have been addressed by XSLT:

For example:
    - rename namespaces
    - compare --> two documents
    - insert --> insert data before/after some nodes
    - delete --> a subtree
    - rename --> a node
    - replace --> replace a subtree with another subtree
    - pack --> aka. merge two documents
    - set attributes --> attributes manipulation

We note that one of the Required Steps also performs an XSLT
Transformation.

The XSL WG has grave concerns about the duplication of functionality.  The
WG would be extremely disappointed if this were the start of yet another
transformation language.  We are not sure how these constructs would
interact with XSLT.

We could understand if the tasks overlapping with XSLT functionality would
have guaranteed streamability; however this is not the case.  For example,
in section 7.1.18 Rename, "match" is an XSLT MatchPattern that, in the 
general case,
is not streamable.

3. The XProc specification does not make it clear if parallel executions
are handled. (Currently there is implicit parallelism based on connection
between steps.)  This would be a problem for any task involving multiple
processing steps on top of streams.

4. We think it's shortsighted to be using XPath 1.0 rather than 2.0. At 
the
very least, using XPath 2.0 should not be non-conformant.

5. We think it's wrong that support for XSLT 1.0 should be mandatory and
XSLT 2.0 optional. We would suggest that XProc processors be required to
support at least one XSLT version without specifying which one. As 
currently
specified, XProc is storing up a problem for itself in the future when 
XSLT
1.0 starts to fade into obsolescence.

6. Having two separate tasks (step types?) for XSLT 1.0 and XSLT 2.0
suggests a poorly thought-out strategy for versioning. Version control
surely affects processors other than XSLT? A more general mechanism might 
be
to have standard attributes of a task/step that determine the version of 
the
specification and/or implementation required for execution of this step
(allowing users to take the default if they don't care).

Thank you for giving us the opportunity to comment on your specification.
We are anxious to work with you all to resolve these concerns.


Sharon C. Adler
 Senior Manager, Extensible Technologies
 IBM Research
 PO Box 704, Yorktown Heights, NY  10598
 tel:  914-784-6411 t/l 863
 fax: 914-784-6324