[closed] Re: Comments from the XSLT WG on the XProc Last Call Document

/ Sharon Adler <sca@us.ibm.com> was heard to say:
| 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.

Thank you for taking the time to review our specification.

| 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.

As you correctly point out, the use of XPath complicates the question
of whether or not a step is streamable. We're content, at least for
V1, to leave this as a quality of implementation issue.

| 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.

While we acknowledge that many of the steps in XProc could be implemented
with XSLT, the XProc WG believes that our users will be better served
(and their pipelines will be simpler, easier to understand, and easier to
maintain) if we provide explicit steps for these few "transformations".

| We are not sure how these constructs would
| interact with XSLT.

I'm not sure what you mean. They don't interact in any direct way in
XProc because they are separate steps.

| 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.

Indeed. But it is considerably simpler for an implementor to provide
streaming implementations for these steps than it would be to provide
a streamable XSLT step.

Consider, for example, the p:delete step. In my own implementation,
that step *does* stream if an analysis of the match expression reveals
that I can stream it. I would not be able to provide this
functionality in my implementation if it required analysis of the XSLT
"delete' stylesheet.

| 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.

How so?

| 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.

Indeed. We have been persuaded to allow XPath 2.0.

| 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.

Indeed. We have also been persuaded on this point.

| 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).

Indeed. We have been persuaded on this point too. :-)

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

The number and nature of the changes that have been required as a result
of comments on our Last Call draft will make it necessary for us to issue
another Last Call draft :-(

I hope that the XSLT WG will be able to find the time to review the
new draft and see if it still has concerns.

Since we will be doing another Last Call, and as a matter of
convenience to our editors, I have marked this comment as "closed",
but I'd be happy to discuss any concerns you don't feel have been
adequately addressed so far.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The great man is he who has not lost
http://nwalsh.com/            | the heart of a child.-- Mencius