XProc Last Call Comments

From: <Toman_Vojtech@emc.com>
Date: Fri, 31 Oct 2008 04:57:45 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870D404F04@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>


Hi all,

The spec says that the XProc processor should not statically reject
pipelines (or libraries) that refer to steps which the processor does
not support - unless, of course, the processor can detect upfront that
some of these steps will get executed and the pipeline would therefore
fail (but detecting that is usually hard or just impossible). So, in
most cases, the processor will try to run the pipeline and fail with
XD0017 if it encounters an unsupported step.

So far so good. But the thing about unsupported steps is that the
processor not only does not support them, but it also does not know
their declarations - which, among other things, means that it doesn't
know what the step's input and output ports are (and which of them, if
any, are primary). This can cause problems when the processor processes
the pipeline document, establishes the running order of steps and
detects static errors.

The XProc processor has to guess the declarations of the unsupported
steps, which is... not very nice, I must say. In most cases, the
processor will probably try to do its best to make sure that the
pipeline at least executes - based on the context (looking at the way
the step is invoked; using the references from other steps; ...) and in
order to avoid static errors, the processor can assume that the step has
a number of input and output ports with certain properties, these and
these options, etc.

But the guess can be wrong. Also, whether the XProc processor does the
guess at all (and how) is completely implementation-defined, which may
cause annoying problems. Suppose we have two XProc processors: A which
supports x:unsupported-step, and B which does not. Then the following
can happen:

- B accepts a pipeline that A would reject because of static errors.
Here, B guesses some properties of ex:unsupported-step that are not in
the step's declaration.

- Both A and B accept the pipeline, but B executes the steps in
different order. This can happen, for instance, if B manufactures a
primary input port for ex:unsupported-step, but the step declaration
specifies no input port at all. Because of the artificial input port,
the step will be then connected to the primary output port of some other
step...

--

I may be just too immersed in the implementation side of things, so I
may be seeing things worse than they are. But to me, it seems that
"support" for unsupported steps can lead to some interoperability issues
unless the specification states what the XProc processor should do when
it encounters an unsupported step during the *parsing/compilation*
phase. Perhaps the spec could contain a non-normative section with a
(deterministic) algorithm that would describe the "guesses" the XProc
processor can/must make so that the pipeline at least executes.

Any thoughts about this?


Regards,
Vojtech

(Sorry for the long e-mail.)

Received on Friday, 31 October 2008 09:07:42 GMT

[+] Re: Possible problems with unsupported steps from Norman Walsh

[+] RE: Possible problems with unsupported steps from Toman_Vojtech@emc.com

[+] Re: Possible problems with unsupported steps from Norman Walsh

[+] RE: Possible problems with unsupported steps from Toman_Vojtech@emc.com

[+] Re: Possible problems with unsupported steps from Norman Walsh

[+] RE: Possible problems with unsupported steps from Toman_Vojtech@emc.com

[+] [closed] Re: Possible problems with unsupported steps from Norman Walsh

[+] RE: Possible problems with unsupported steps from Toman_Vojtech@emc.com

[+] Re: Possible problems with unsupported steps from James Fuller

051.[+] err:XS0003 and err:XS0022 - duplicates? from Toman_Vojtech@emc.com on 27-Oct-2008

[+] [closed] Re: err:XS0003 and err:XS0022 - duplicates? from Norman Walsh

050.[+] p:viewport-source - err:XD0006 or err:XD0003? from Toman_Vojtech@emc.com on 27-Oct-2008

[+] [closed] Re: p:viewport-source - err:XD0006 or err:XD0003? from Norman Walsh

049.[+] Standard C14N method or option for serialization? from Norman Walsh on 21-Oct-2008

[+] Re: Standard C14N method or option for serialization? from mozer

[+] [closed] Re: Standard C14N method or option for serialization? from Norman Walsh

048.[+] p:log on atomic steps? from Norman Walsh on 20-Oct-2008

[+] Re: p:log on atomic steps? from Josh Matthews

[+] Re: p:log on atomic steps? from Norman Walsh

[+] [closed] Re: p:log on atomic steps? from Norman Walsh

047.[+] p:wrap-sequence : the context should have access to position() and last() from Innovimax SARL on 20-Oct-2008

[+] Re: p:wrap-sequence : the context should have access to position() and last() from Norman Walsh

[+] [closed] Re: p:wrap-sequence : the context should have access to position() and last() from Norman Walsh

046.[+] href on p:store from Norman Walsh on 19-Oct-2008

[+] RE: href on p:store from Toman_Vojtech@emc.com

[+] [closed] Re: href on p:store from Norman Walsh

045.[+] split-sequence: position() and last() from Norman Walsh on 16-Oct-2008

[+] Re: split-sequence: position() and last() from mozer

[+] [closed] Re: split-sequence: position() and last() from Norman Walsh

044.[+] source on p:error from Norman Walsh on 14-Oct-2008

[+] Re: source on p:error from Henry S. Thompson

[+] Re: source on p:error from Norman Walsh

[+] Re: source on p:error from Henry S. Thompson

[+] [closed] Re: source on p:error from Norman Walsh

043.[+] Explicit vs. implicit parameter bindings from Norman Walsh on 12-Oct-2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Sun, 12 Oct 2008 11:48:38 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2bpxp3jc9.fsf@nwalsh.com>

Consider this pipeline:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
		xmlns:px="http://example.org/ns/pipelines"
		xmlns:c="http://www.w3.org/ns/xproc-step"
		name="main">
<p:input port="parameters" kind="parameter">
  <p:inline>
    <c:param-set>
      <c:param name="foo" value="1"/>
    </c:param-set>
  </p:inline>
</p:input>
<p:input port="source"/>
<p:output port="result">
  <p:pipe step="params" port="result"/>
</p:output>

<p:parameters name="params">
  <p:input port="parameters">
    <p:pipe step="main" port="parameters"/>
  </p:input>
  <p:with-param name="foo" select="'bar'"/>
</p:parameters>

</p:declare-step>

The output of this pipeline is a c:param-set element with "foo='bar'"
because the with-param occurs after the parameter input port.

If we reverse the order of the elements in the p:parameters step:

<p:parameters name="params">
  <p:with-param name="foo" select="'bar'"/>
  <p:input port="parameters">
    <p:pipe step="main" port="parameters"/>
  </p:input>
</p:parameters>

Then the output of this pipeline is a c:param-set element with "foo='1'"
because the with-param occurs before the parameter input port.

We all agree so far, right?

So what's the output if we specify the p:parameters step this way?

<p:parameters name="params">
  <p:with-param name="foo" select="'bar'"/>
</p:parameters>

In other words, what is the relative order of the implicit bindings?

I'm inclined to say they come last, that they come after the things
that you specify explicitly. But I think that by the principle of
least surprise, the value specified by the lone with-param should be
respected.

Thoughts?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | I'm NOT in denial!
http://nwalsh.com/            |

Received on Sunday, 12 October 2008 15:49:22 GMT

[+] RE: Explicit vs. implicit parameter bindings from Toman_Vojtech@emc.com

From: <Toman_Vojtech@emc.com>
Date: Mon, 13 Oct 2008 03:41:22 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870CF6EABC@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-wg@w3.org>


> Consider this pipeline:
> 
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
> 		xmlns:px="http://example.org/ns/pipelines"
> 		xmlns:c="http://www.w3.org/ns/xproc-step"
> 		name="main">
> <p:input port="parameters" kind="parameter">
>   <p:inline>
>     <c:param-set>
>       <c:param name="foo" value="1"/>
>     </c:param-set>
>   </p:inline>
> </p:input>
> <p:input port="source"/>
> <p:output port="result">
>   <p:pipe step="params" port="result"/>
> </p:output>
> 
> <p:parameters name="params">
>   <p:input port="parameters">
>     <p:pipe step="main" port="parameters"/>
>   </p:input>
>   <p:with-param name="foo" select="'bar'"/>
> </p:parameters>
> 
> </p:declare-step>
> 
> The output of this pipeline is a c:param-set element with "foo='bar'"
> because the with-param occurs after the parameter input port.
> 
> If we reverse the order of the elements in the p:parameters step:
> 
> <p:parameters name="params">
>   <p:with-param name="foo" select="'bar'"/>
>   <p:input port="parameters">
>     <p:pipe step="main" port="parameters"/>
>   </p:input>
> </p:parameters>
> 
> Then the output of this pipeline is a c:param-set element 
> with "foo='1'"
> because the with-param occurs before the parameter input port.
> 
> We all agree so far, right?
> 
> So what's the output if we specify the p:parameters step this way?
> 
> <p:parameters name="params">
>   <p:with-param name="foo" select="'bar'"/>
> </p:parameters>
> 
> In other words, what is the relative order of the implicit bindings?
> 
> I'm inclined to say they come last, that they come after the things
> that you specify explicitly. But I think that by the principle of
> least surprise, the value specified by the lone with-param should be
> respected.
> 
> Thoughts?
> 

I think this has already been addressed in Section 5.1.2 (Parameter
Inputs):

"If a binding is manufactured for a primary parameter input port, that
binding occurs logically last among the other parameters, options, and
bindings passed to the step. In other words, the parameter values that
appear on that port will be used even if other values were specified
with p:with-param elements. Users can change this priority by making the
binding explicit and placing any p:with-param elements that they wish to
function as overrides after the binding."

Regards,
Vojtech

Received on Monday, 13 October 2008 07:42:14 GMT

[+] Re: Explicit vs. implicit parameter bindings from Norman Walsh

042.[+] Detecting errors from Norman Walsh on 09-Oct-2008

[+] Re: Detecting errors from mozer

[+] RE: Detecting errors from Toman_Vojtech@emc.com

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 GMT

[+] Re: Detecting errors from Josh Matthews

[+] Re: Detecting errors from Henry S. Thompson

[+] Re: Detecting errors from Norman Walsh

[+] [closed] Re: Detecting errors from Norman Walsh

041.[+] Steps with no input/output ports from Toman_Vojtech@emc.com on 09-Oct-2008

[+] Re: Steps with no input/output ports from Alex Milowski

[+] [closed] Re: Steps with no input/output ports from Norman Walsh

040.[+] C14N remark from Toman_Vojtech@emc.com on 08-Oct-2008

[+] Re: C14N remark from Innovimax SARL

[+] Re: C14N remark from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 08 Oct 2008 11:42:02 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m263o3ksad.fsf@nwalsh.com>

Toman_Vojtech@emc.com writes:

>>From the meeting minutes October 2:
>
>>   ... On C14N, we've already discussed this and said it was a
> user-defined
>>   option on serialization.
>>
>>   Norm: Good point! Thank you, Mohamed.
>
> True, but do we mention this in the spec somewhere? (Perhaps we don't
> have to...)

We probably should provide an optional p:c14n serialization method
that does C14N. At least that way, implementors won't have to invent
their own.

Or is that not the right way to trigger it?

> It just occurred to me that having C14N as an option on p:serialization
> can make using C14N in XProc quite tedious. Because it is on the
> p:serialization level, you can do C14N only in environments where you
> actually *serialize* the outputs (p:store or when you run a pipeline in
> a shell, for instance).

But C14N is defined to produce a sequence of characters. I don't think
it's meaningful to speak of a C14N infoset.

> But if you want to do C14N in step A and then
> pass its (canonicalized) output to step B, you are in trouble. You will
> have to run step A, store its result (with C14N turned on) to an
> external location, and let step B read the data from there. Not very
> nice nor reliable, I think.

Doesn't

  <p:wrap wrapper="c14n-content" match="/*"/>
  <p:escape-markup method="p:c14n"/>

do what you want? That will return a <c14n-content> document that
contains a single text node which is the C14N'd characters.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | All the labors of the ages, all the
http://nwalsh.com/            | devotion, all the inspiration, all the
                              | noonday brightness of human genius, are
                              | destined to extinction.--Bertrand
                              | Russell

Received on Wednesday, 8 October 2008 16:59:53 GMT

[+] RE: C14N remark from Toman_Vojtech@emc.com

039.[+] Mutually recursive calling from Innovimax SARL on 06-Oct-2008

[+] Re: Mutually recursive calling from Norman Walsh

[+] Re: Mutually recursive calling from Innovimax SARL

[+] Re: Mutually recursive calling from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 08 Oct 2008 12:58:47 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2vdw3dqa9.fsf@nwalsh.com>

"Innovimax SARL" <innovimax@gmail.com> writes:

>> Section 3.2 says, in part, the "step types visible in a pipeline or
>> library are ... for a pipeline in a library, the types visible in the
>> containing library."
>>
>> From that, I think it follows that if you put both of these steps in a
>> library, then they would be visible to each other. It's not clear if
>> they're visible to each other in a p:pipeline, but I expect they
>> should be.
>
> I expect too, but could it be clearer in the spec ?

Does this rewrite make things clearer?

   The scope of the names of the step types is the pipeline in which they are
   declared, including any declarations imported from libraries via
   p:import. Nested pipelines inherit the step types in scope for their
   parent.

   In other words, the step types that are in scope in a p:pipeline or
   p:declare-step are:

     * The standard, built-in types (p:pipeline, p:choose, etc.).

     * Any implementation-provided types.

     * Any step types declared in the pipeline.

     * The types of an p:pipelines or p:declare-steps that are
       imported.

     * Any types that are in the scope of any p:library that is
       imported.

     * Any step types that are in scope for the pipeline's parent
       p:pipeline or p:declare-step, if it has one.

     * The type of the pipeline itself, if it has one.

   The step types that are in scope in a p:library are:

     * The standard, built-in types (p:pipeline, p:choose, etc.).

     * Any implementation-provided types.

     * Any step types declared in the library (the p:pipeline and
       p:declare-step children of the p:library element).

     * The types of an p:pipelines or p:declare-steps that are
       imported into the library.

     * Any types that are in the scope of any p:library that is
       imported.

>> (But don't hold your breath for Calabash support :-(; my current
>> loader is a one-pass process and you can't make this work with a
>> one-pass loader.)
>
> Too bad :(

Actually, maybe it'll happen sooner than I expected. I'm in the middle
of some major surgery on the way pipelines are evaluated.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Young men think old men are fools; but
http://nwalsh.com/            | old men know young men are
                              | fools.--George Chapman

Received on Wednesday, 8 October 2008 16:59:42 GMT

[+] Re: Mutually recursive calling from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Wed, 8 Oct 2008 19:27:07 +0200
Message-ID: <546c6c1c0810081027x17e8ea57qaf675ab83754c062@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org


Norm,

It works for me

PS : I'm glad to hear that for Calabash !!

Mohamed

On Wed, Oct 8, 2008 at 6:58 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> "Innovimax SARL" <innovimax@gmail.com> writes:
>
>>> Section 3.2 says, in part, the "step types visible in a pipeline or
>>> library are ... for a pipeline in a library, the types visible in the
>>> containing library."
>>>
>>> From that, I think it follows that if you put both of these steps in a
>>> library, then they would be visible to each other. It's not clear if
>>> they're visible to each other in a p:pipeline, but I expect they
>>> should be.
>>
>> I expect too, but could it be clearer in the spec ?
>
> Does this rewrite make things clearer?
>
>   The scope of the names of the step types is the pipeline in which they are
>   declared, including any declarations imported from libraries via
>   p:import. Nested pipelines inherit the step types in scope for their
>   parent.
>
>   In other words, the step types that are in scope in a p:pipeline or
>   p:declare-step are:
>
>     * The standard, built-in types (p:pipeline, p:choose, etc.).
>
>     * Any implementation-provided types.
>
>     * Any step types declared in the pipeline.
>
>     * The types of an p:pipelines or p:declare-steps that are
>       imported.
>
>     * Any types that are in the scope of any p:library that is
>       imported.
>
>     * Any step types that are in scope for the pipeline's parent
>       p:pipeline or p:declare-step, if it has one.
>
>     * The type of the pipeline itself, if it has one.
>
>   The step types that are in scope in a p:library are:
>
>     * The standard, built-in types (p:pipeline, p:choose, etc.).
>
>     * Any implementation-provided types.
>
>     * Any step types declared in the library (the p:pipeline and
>       p:declare-step children of the p:library element).
>
>     * The types of an p:pipelines or p:declare-steps that are
>       imported into the library.
>
>     * Any types that are in the scope of any p:library that is
>       imported.
>
>>> (But don't hold your breath for Calabash support :-(; my current
>>> loader is a one-pass process and you can't make this work with a
>>> one-pass loader.)
>>
>> Too bad :(
>
> Actually, maybe it'll happen sooner than I expected. I'm in the middle
> of some major surgery on the way pipelines are evaluated.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | Young men think old men are fools; but
> http://nwalsh.com/            | old men know young men are
>                              | fools.--George Chapman
>



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Wednesday, 8 October 2008 17:27:46 GMT

038.[+] On the interpretation of match= from Norman Walsh on 05-Oct-2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Sun, 05 Oct 2008 12:43:00 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2ljx3uh63.fsf@nwalsh.com>

Jim Fuller started a thread[1] on the xproc-dev mailing list which has
evolved into a question of spec interpretation. Jim's original
question was about p:delete, but I'm going to rephrase it using
p:rename in order to better illustrate one of the examples.

For the following discussion, assume that the this document occurs on
the default readable port:

<doc>
  <m>//item</m>
  <!-- hello world -->
  <item>an item</item>
</doc>

I think the spec is clear that both of these are valid:

  <p:rename match="//item" new-name="foo"/>

  <p:rename match="//no-such-item" new-name="foo"/>

The former renames the "item" to "foo", the latter does nothing
because there are no elements named "no-such-item".

I think the following is also clearly valid:

  <p:rename new-name="foo">
    <p:with-option name="match" select="/doc/m"/>
  </p:rename>

The value of the match attribute is taken from the string-value of the
/doc/m node which is "//item" so this step is functionally the same as
the very first example above.

I think it's also clear that the following is invalid:

  <p:rename match="/doc/node()[4]" new-name="foo"/>

The matched node is a comment and rename cannot target comments.

But what about this example:

  <p:rename new-name="foo">
    <p:with-option name="match" select="/doc/a"/>
  </p:rename>

There's some debate on the xproc-dev thread about it, but after
looking through the XSLT 2.0 spec, I'm pretty confident that it's an
error.

I think the shortest argument why is that the BNF for an XSLT 2.0
Pattern[2] (which we call an XSLTMatchPattern and still need to cite a
little more carefully) cannot be empty.

                                        Be seeing you,
                                          norm


[1] http://markmail.org/message/otaebbniqetguf6w
[2] http://www.w3.org/TR/xslt20/#dt-pattern

-- 
Norman Walsh <ndw@nwalsh.com> | A moment's insight is sometimes worth a
http://nwalsh.com/            | life's experience.--Oliver Wendell
                              | Holmes

Received on Sunday, 5 October 2008 16:43:42 GMT

[+] Re: On the interpretation of match= from Florent Georges

[+] Re: On the interpretation of match= from mozer

[+] Re: On the interpretation of match= from Florent Georges

[+] Re: On the interpretation of match= from Norman Walsh

[+] Re: On the interpretation of match= from Florent Georges

[+] Re: On the interpretation of match= from Norman Walsh

[+] Re: On the interpretation of match= from Josh Matthews

037.[+] Self importing from Innovimax SARL on 05-Oct-2008

[+] Re: Self importing from Norman Walsh

[+] [closed] Re: Self importing from Norman Walsh

036.[+] Make 5.7.2 consistent wrt context node from Norman Walsh on 01-Oct-2008

[+] Re: Make 5.7.2 consistent wrt context node from Norman Walsh

[+] [closed] Re: Make 5.7.2 consistent wrt context node from Norman Walsh

035.[+] Another look at validate-with-xml-schema from Vasil Rangelov on 28-Sep-2008

[+] Re: Another look at validate-with-xml-schema from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Sun, 28 Sep 2008 15:03:05 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m28wtc855i.fsf@nwalsh.com>

"Vasil Rangelov" <boen.robot@gmail.com> writes:

> 1. As far as I know, "lax" mode refers to validating the XML document
> against the schema declared inside of it if available, and assume valid if
> no such schema is declared. "strict" refers to validating the XML document
> against the schema declared inside of it and assume invalid if no such
> schema is declared. Shouldn't those two modes be clarified? If this is said
> elsewhere (say, the XML Schema spec), there should be a reference to the
> relevant section.

Strict and lax are validation options provided by XML Schema. A
cursory skim through the XML Schema spec didn't yield an obvious place
to point. Henry, can you suggest some clarifying text or a good place
to point into in the XML Schema spec?

> 2. Is the "schema" port required? If not, how does the processor behave when
> it's not present? Against the mode I suppose? This should be said
> explicitly.

The port is always required, but you can bind p:empty to it.

Perhaps we could clarify how the schema processor is expected to use the
schemas so passed (or not) and what other schemas it may use. Henry?

> 3. What exactly is the point of the assert-valid option? If assert-valid is
> "false" and the document turns out to be invalid, what should happen?
> Nothing?!? Why so?

You get a PSVI. Maybe you can make use of the PSVI for a partially
valid document, maybe you can't. If you can't, don't ask for it :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything we love, no doubt, will pass
http://nwalsh.com/            | away, perhaps tomorrow, perhaps a
                              | thousand years hence. Neither it nor
                              | our love for it is any the less
                              | valuable for that reason.--John Passmore

Received on Sunday, 28 September 2008 19:03:50 GMT

[+] Re: Another look at validate-with-xml-schema from Henry S. Thompson

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 29 Sep 2008 10:36:49 +0100
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org
Message-ID: <f5b63ofqoni.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norman Walsh writes:

> Strict and lax are validation options provided by XML Schema. A
> cursory skim through the XML Schema spec didn't yield an obvious place
> to point. Henry, can you suggest some clarifying text or a good place
> to point into in the XML Schema spec?

This distinction is not defined in XML Schema 1.0 as such.  XML Schema
1.1 gives definitions which correspond to this distinction, but make
clear that it is really an option for the _invoking_ application.
Accordingly, I would recommend this para., borrowed from Schema 1.1:

  'Strict' mode means that the document element must be declared and
  schema-valid, otherwise it will be treated as invalid, that is, an
  error will result if assert-valid is 'true'.  'Lax' mode means that
  the absence of a declaration for the document element does not
  itself count as an unsuccessful outcome of validation.

>> 2. Is the "schema" port required? If not, how does the processor behave when
>> it's not present? Against the mode I suppose? This should be said
>> explicitly.
>
> The port is always required, but you can bind p:empty to it.
>
> Perhaps we could clarify how the schema processor is expected to use the
> schemas so passed (or not) and what other schemas it may use. Henry?

The schema spec. leaves all this up to the implementation.  We can
either follow suit, and say it's all impl. defined, or we could
provide options.  Here's some informal prose we _could_ use to do the
latter:

  useSchemaLocation select="'false'" If true, attempt to dereference
  xsi:schemaLocation and xsi:noNamespaceSchemaLocation URIs to find
  schema documents.

  tryNamespace select="'false'" If true, dereference namespace URIs
  for otherwise unknown namespaces to find schema documents.

  Schema documents found on the 'schema' input port *must* be
  processed to contribute to the schema used for schema validation.

  It is a dynamic error ??? if the schema validator used by an
  implementation does not support any of the modes of schema document
  location specified by the values of useSchemaLocation and
  tryNamespace and the presence or absence of schema documents on the
  'schema' input port.

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFI4KGxkjnJixAXWBoRAoudAJ0bbB72FzWtrQQ0s1EP06Sjnhy4ngCfW3jI
iPwUtzW6FlGDxk5E+FtT1dQ=
=t9Cr
-----END PGP SIGNATURE-----

Received on Monday, 29 September 2008 09:39:26 GMT

[+] [closed] Re: Another look at validate-with-xml-schema from Norman Walsh

034.[+] Proposal for XProc: add output port to p:validate-with-xml-schema from James Garriss on 26-Sep-2008

[+] Re: Proposal for XProc: add output port to p:validate-with-xml-schema from Henry S. Thompson

[+] [closed] Re: Proposal for XProc: add output port to p:validate-with-xml-schema from Norman Walsh

033.[+] p:validate-with-schematron report defect from Florent Georges on 24-Sep-2008

[+] Re: p:validate-with-schematron report defect from Norman Walsh

[+] Re: p:validate-with-schematron report defect from Florent Georges

[+] [closed] Re: p:validate-with-schematron report defect from Norman Walsh

[+] Re: [closed] Re: p:validate-with-schematron report defect from Florent Georges

[+] Re: [closed] Re: p:validate-with-schematron report defect from Rui Lopes

[+] Re: [closed] Re: p:validate-with-schematron report defect from Florent Georges

[+] Re: [closed] Re: p:validate-with-schematron report defect from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 03 Oct 2008 09:35:18 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2ljx594yx.fsf@nwalsh.com>

"Florent Georges" <fgeorges@fgeorges.org> writes:

>> The WG agreed to suggest that the output SHOULD be SVRL.
>
>   That's better than nothing.  On the other side, that means that one
> can not rely on the step's output format, thus she couldn't use the
> report output to transform it in HTML for instance, nor to report any
> meaningful info to the user in any way.

I understand your concern, but the WG is trying to be pragmatic.
Realistically, implementors are going to want to incorporate
off-the-shelf implementations of as many steps as they possibly can.
I'm using Saxon, for example, for the XSLT and Query steps, Kohsuke's
MSV for RELAX NG validation, etc.

I haven't figured out how I'm going to support Schematron, but
whatever package I pick to do it, is going to produce some sort of
output. I don't want to be prevented from using what might be my only
practical option just because it produces output that isn't in SVRL.

>   Maybe we could have an optional option to set the expected report
> format (html, svrl, or an implementation-defined value) ?

Again, unless it's clear that off-the-shelf toolkits offer this
capability out-of-the-box, I don't think the WG will be persuaded to
go there.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Between the ages of twenty and forty we
http://nwalsh.com/            | are engaged in the process of
                              | discovering who we are, which involves
                              | learning the difference between
                              | accidental limitations which it is our
                              | duty to outgrow and the necessary
                              | limitations of our nature beyond which
                              | we cannot trespass with impunity.--W.
                              | H. Auden

Received on Friday, 3 October 2008 13:35:59 GMT

[+] Re: [closed] Re: p:validate-with-schematron report defect from Florent Georges

032.[+] LCWD comment on p:validate-with-schematron from Jirka Kosek on 24-Sep-2008

[+] Re: LCWD comment on p:validate-with-schematron from Dave Pawson

[+] Re: LCWD comment on p:validate-with-schematron from Florent Georges

[+] Re: LCWD comment on p:validate-with-schematron from Norman Walsh

[+] Re: LCWD comment on p:validate-with-schematron from Jirka Kosek

XProc Last Call Comments

Last updated: 13 Nov 2008 at 18:38:00 UTC