W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2008

RE: Detecting errors

From: <Toman_Vojtech@emc.com>
Date: Thu, 9 Oct 2008 09:14:08 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870CECF0FA@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>

> Consider the following pipeline:
> 
> <p:declare-step name="main" ...>
>   <p:input port="source"/>
>   <p:output port="source"/>
> 
>   <p:declare-step type="px:unused">
>     <p:input port="source"/>
>     <p:output port="source"/>
>     <px:undeclared/>
>   </p:declarestep>
> 
>   <p:identity/>
> </p:declare-step>
> 
> (a) Does this pipeline contain an error?
> (b) Are implementations allowed to report it?
> (c) Are implementations required to report it?
> 
> I think the answer to (a) is yes. I think the answers to (b) and (c)
> should either both be yes or both be no, for interoperability reasons.
> I'm inclined towards yes, but I'm not sure the spec gives a definitive
> answer.

Hm. Currently, our XProc implementation would reject this pipeline. It
would also reject this library:

<p:library>
  <p:declare-step type="px:unused">
    <p:input port="source"/>
    <p:output port="source"/>
    <px:undeclared/>
  </p:declare-step>
  <p:declare-step type="px:used">
    <p:input port="source"/>
    <p:output port="source"/>
    <px:undeclared/>
  </p:declare-step>
<p:library>

So, I would like to say that the answers to all questions is yes. But...
consider this pipeline:

<p:declare-step name="main" ...>
  <p:input port="source"/>
  <p:output port="source"/>

  <p:declare-step type="px:unused">
    <p:input port="source"/>
    <p:output port="source"/>
    <p:choose>
      <p:when test="p:step-available('px:undeclared')">
        <px:undeclared/>
      </p:when>
      <p:otherwise>
        <p:error .../>
      </p:otherwise>
    </p:choose>
  </p:declare-step>

  <p:identity/>
</p:declare-step>

In this case, the processor should not reject the pipeline (it contains
no error), but detecting this upfront can be difficult (or impossible)
because the decision depends on the runtime result of an XPath
expression (p:when test="...").

In the initial example, there is no runtime decision involved, but how
can the processor know/detect that? The pipeline can be really
complicated, and in many cases, the only way to test whether the
pipeline is correct or not is to simply run it and see...

So, now I tend to think that we should not demand that the processors
reject pipelines with undeclared steps upfront, and only stick to what
we say in section 4.8 (Extension steps): It is a dynamic error
(err:XD0017) if the running pipeline attempts to invoke a step which the
processor does not know how to perform." Of course, if the processor is
clever enough to reject such a pipeline upfront, I don't see any reason
why it couldn't (the pipeline would fail anyway).

Regards,
Vojtech
Received on Thursday, 9 October 2008 13:15:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:25 UTC