I think p:import-schema is too big and too late for V1

After further consideration, I think we're making a mistake with
p:import-schema. We should remove it from V1 and describe it as a
possible V.next feature. In no particular order:

1. When we started this spec, we agreed that all we really needed was
XPath 1.0. I'm not saying that was everyone's position, but it was the
consensus position. I understand that we've been persuaded to support
XPath 2.0, but does anyone have any real use cases for schema support?

2. Our spec allows pipeline definitions to be nested and allows
pipeline definitions to be stored in external libraries. When we saw
this complexity, we brushed it aside with "we'll do what XSLT does".
I'm no longer sure that it's safe to just accept that answer. I'm not
sure the use cases for XSLT and XProc are sufficiently similar to
justify taking that answer lightly.

I think if the WG is determined to proceed with schema import, we need
to stop and consider carefully how imported schemas impact the static
context and how that context might differ from pipeline to pipeline
depending on where it was defined.

Consider the following use case. Suppose I have a pipeline that
processes V2 of the Widget Markup Language. Some bright spark who's
still using V1 of WML thinks he can be clever, so he writes a pipeline
that uses the V1 schema to process V1 documents into V2 documents. Now
he tries to combine his transformation and my processing into a new
pipeline and it fails because he's trying to import two different
schemas for the same namespace.

3. It's even worse than that. We've agreed that the static context
constructed by the pipeline processor is the static context made
available to steps. We have to do this for some steps (so that they
can evaluate expressions containing named types) so we do it for all
steps.

This means that an XSLT or XQuery step that does its own schema
importing might fall over if I've imported a pipeline library that
imports a schema, even if I'm not using that schema or any steps that
use that schema in my pipeline.

4. It creates even more comlpexity in the spec because it introduces
*another* class of processor. Right now there are XPath1 processors
and XPath2-only processors and XPath2-with-XPath1-bc-processors.
With schema import there will be XPath1 processors
and XPath2-only-basic-processors and XPath2-only-schema-aware processors
and XPath2-with-XPath1-bc-processors-basic-processors and
XPath2-with-XPath1-bc-processors-schema-aware-processors.

Ugh.

I feel very strongly that we should not put schema awareness into
XProc V1. I'm not even content to do it as an "at risk" feature.
I'm afraid that we're making a whole set of complex decisions without
the care and consideration that they deserve.

Rather than putting the feature in "at risk," I think we should invite
implementors to experiment with schema support in
implementation-dependent ways and revisit this issue if and when we
consider V2.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Much of the social history of the
http://nwalsh.com/            | Western world over the past three
                              | decades has involved replacing what
                              | worked with what sounded good.--Thomas
                              | Sowell