Re: Comment

Deborah_Pickett@moldflow.com
>If I were to be running such a server, I would be worried about allowing a
p:directory-list step to run on the server.*
>Certain steps can throw a dynamic error if they would otherwise violate the
security policy for the environment that the pipeline is running in.

That is precisely what p:directory-list allows implementations to do if the
step cannot be completed.

See
"
It is a dynamic error (err:XC0012) if the contents of the directory path are
not available to the step due to access restrictions in the environment in
which the pipeline is run.
"
Do you have any other steps in mind that would need to have such explicit
statement? I can only think of p:store (which I've always believed should be
called p:save) but it has such a statement too.

>One of the wisest things, IMHO, that the XSLT working group did was to nail
down forward-compatible behaviour for XSLT 1.0 processors running future-
>versioned stylesheets.  I can see this being equally important for XProc. 
>
>Is this a legitimate concern?  If not, why not?

In general, the spec *seems* to say that if a step is not implemented or
unavailable, it fails. And whenever a step "fails" it produces an error
document which can be handled with p:catch. If not, I suppose it would be a
static error, which you could recover from with p:step-available(). It does
need clarification though. I agree.

Still, this also sort of sorts out forwards compatibility. If a step
provided in XProc 2.0 is not implemented, it (the step or the condition to
detect it) fails on the spot.

>I could find no mention in the 20 September 2007 draft of how an XProc
pipeline instance indicates the version of XProc that it was written for
>(something akin to xsl:stylesheet/@version for XSLT).

I agree it's needed. And it has been discussed before. The argument I
remember reading was that p:pipeline can occur in p:pipeline-library, and
p:pipeline imports p:pipeline-library. So, we get a total mess with all
possibilities that need to be sorted out. I kind of wonder how did the WG
get to last call without sorting this.

The questions I mean are -
What happens if p:pipeline/@version="1.0" imports
p:pipeline-library/@version="2.0"?
What happens if p:pipeline/@version="2.0" imports
p:pipeline-library/@version="1.0"?
What happens if p:pipeline-library/@version="1.0" contains
p:pipeline/@version="2.0"? 
What happens if p:pipeline-library/@version="2.0" contains
p:pipeline/@version="1.0"?
What happens if p:pipeline/@version="1.0" imports
p:pipeline-library/@version="2.0" containing p:pipeline/@version="1.0"? 
What happens if p:pipeline/@version="2.0" imports
p:pipeline-library/@version="1.0" containing p:pipeline/@version="2.0"?

And there may be more, but I can't think of them now.

A simple solution you might say will be to prohibit @version on p:pipeline
elements inside p:pipeline-library, leaving only the first two questions to
be settled. Yes, but the WG needs to express the language in XML Schema. I
personally think it's worth it to make it so that such documents validate
against the schema, but still make it a static error if p:pipeline-library
has no version attribute and it's p:pipeline elements have.

>I am somewhat confused over the exact intent of the separation of p:xslt
and p:xslt2

I think it's because XSLT 2.0 supports needs to be optional due to the not
that many XSLT 2.0 processors out there. The specification also doesn't
provide any conditional options (so that specifying one option would
enable/disable others), and providing such would seem like an overkill for
both language complexity and implementation requirements. As a last resort,
the two steps were just separated.

>- If I run a p:xslt step, and the XProc implementation implements p:xslt by
calling an external XSLT 1.0 processor like libxslt or Xalan, do I get a
>static or dynamic error if the external XSLT processor is absent?  (I would
assume dynamic.  I think that the draft says this, but I want to check my
>understanding.)
>- If I run a p:xslt2 step, and the XProc implementation implements p:xslt2
by delegating to an external XSLT processor such as Saxon 8, do I get a
>static or dynamic error if the external XSLT processor is absent?  (I would
assume dynamic.)

In both cases, the step fails with a dynamic error, catchable in p:catch...
I think.

>- If I run a p:xslt step using an XSLT 2.0 stylesheet (or an XSLT 1.0
stylesheet that imports 2.0 snippets), am I guaranteed that I will get an
XSLT 1.0
>processor running in forwards-compatible mode (a la XSLT 1.0 spec)?  (In
other words, is it non-conformant for an XProc implementation to delegate
>processing to an external processor like JAXP if the latter is at risk of
running an XSLT 2.0 processor if that's the only XSLT processor the user has
>installed?)

I think so. The XProc processor is suppose to invoke external processors to
do the work, so if those processors are conformant, you should get
forwards-compatible behavior.

>- I want to define a step that invokes the "best available" XSLT processor.
Would it make sense to implement that as a combination of p:step-
>available("p:xslt2") (to fend off static errors) and p:try/p:catch (to
recover from dynamic errors due to absent processors)?  Given XSLT's very
good
>cross-version compatibility, would such a step be useful enough to enter
the standard library?

I think not. If it was, p:xslt and p:xslt2 were going to be combined
already. Again, how will you handle options available only in XSLT 2.0 and
how will this step react if there's no input document provided, but the XSLT
processor seems to be XSLT 1.0?

>- If I run a p:xslt2 step and the XProc implementation dosn't implement
p:xslt2, do I get a static or dynamic error?  (I would assume static.  I
think >that the draft says this, but I want to check my understanding.)

That's a good one. And it practically applies to all steps from the standard
library (I don't see any generic clarification on that). I think you're
right. It should probably be static.

mike@saxonica.com
> Why are p:document and p:load distinct?

Yeah, I was also wondering about that recently and I was thought on it by
Jeni Tennison earlier this month
http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/200
7Sep/0004.html

>2. Nomenclature. "validate-xml-schema" is a misleading name for a step that
validates an instance.
Now that you've mentioned it, isn't that also the case with RNG and
Schematron?

Still, if the spec is to say something like p:validate-*-instance, it would
become confusing for an average pipeline author. So there's a need for some
compromise here. What name would you suggest?

Regards,
Vasil Rangelov

Received on Monday, 24 September 2007 12:01:01 UTC