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

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

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

031.[+] .xpl? bah humbug from Norman Walsh on 23-Sep-2008

[+] Re: .xpl? bah humbug from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Tue, 23 Sep 2008 16:24:30 +0200
Message-ID: <546c6c1c0809230724w457eb19eq348c769060cee0a7@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org, ebruchez@orbeon.com, avernet@orbeon.com

If I'm not wrong

In http://www.w3.org/XML/XProc/2007/12/20-minutes

the point 86

[[
 86. A really important question

  Norm: This what extension to use...

  Henry: Whatever convention we establish, people will follow.
  ... We ought to give a little thought to the extension
  ... We could just expose them as .xml
  ... Since we're toying with a media type, web server administrators will
  be unhappy if we don't pick a suffix.

  <ht> allinurl: xpl filetype:xpl

  Henry: There are about 8000 pages that end in .xpl
  ... Orbeon uses .xpl

  Alessandro: works for me!

  Henry: So is this the way we're going

  Norm: I'm not really fond of the idea of making a statement directly about
  it in the spec, but I'm happy to use .xpl in examples and the test suite,
  etc.

  Henry: We have an issue about the media type stuff and fragment
  identifiers. We'll get back to this, indirectly, when we cover that issue.

  Norm: I'm happy that we have an informal consensus to use .xpl, but I
  don't feel like we need to add it to the spec just yet.

  Alessandro: The XSLT spec says that most of the stylesheets use the
  extension .xsl

  Norm: Right, in the media type spec, I'm happy to do that too.
]]

On Tue, Sep 23, 2008 at 3:31 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> From private correspondence:
>
> > I know this is not relevant to [...], but
> > the *.xpl extension is used by Orbeon's pipeline definition files yet
> > (in a language called XPL.)  Maybe it would be worth avoiding
> > confusion and don't spread this usage for XProc files?  Maybe using
> > just *.xp, or using *.xproc would be better?
>
> Do we want to reconsider .xpl?
>
> (Erik/Alessandro, were you guys paying attention when we picked .xpl?)
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | More imagination would indeed be a mere
> http://nwalsh.com/            | trifling; only no imagination is
>                              | *mere*.--C. S. Peirce
>

-- 
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 Tuesday, 23 September 2008 14:25:09 GMT

[+] [closed] Re: .xpl? bah humbug from Norman Walsh

030.[+] LCWD comments from XML Query and XSL WGs from Andrew Eisenberg on 22-Sep-2008

From: Andrew Eisenberg <andrew.eisenberg@us.ibm.com>
Date: Mon, 22 Sep 2008 14:37:17 -0400
To: public-xml-processing-model-comments@w3.org
Cc: Jim Melton <jim.melton@acm.org>, Sharon Adler <sca@us.ibm.com>, Norman Walsh <ndw@nwalsh.com>
Message-ID: <OF7A3ED369.BE2D389A-ON852574CC.00659545-852574CC.006649D5@us.ibm.com>

The XML Query and XSL WGs approved the following comments on the XProc 
LCWD [1] at our meeting on Sept. 16:



1) 2.6.2.2 Step XPath Context, minor technical

Some of these items should specify that they are augmenting the values 
provided by an implementation: Statically known namespaces, Default 
element/type namespace, In-scope schema definitions, In-scope variables, 
and Function signatures.

An XPath implementation might provide some statically known namespaces, 
for example, that are then augmented by those of p:namespaces, rather than 
overwritten by them. 


2) 5.14 p:data, editorial

Examples use p:file, rather than p:data.


3) 7.2.9 p:xquery, bulleted list beginning "The query port ...", editorial

The 4th bullet does not recognize the third bullet. It should be changed 
to "Otherwise, the interpretation of the query is implementation-defined."


4) 7.2.9 p:xquery, "The static context is augmented as follows:", minor 
technical

The static and dynamic context would be better stated independently of 
section 2.6.2.2 Step XPath Context. That section is written rather 
narrowly. It does not, for example, allow namespaces known a priori to the 
XQuery implementation. We suggest the following:


The static context of the XQuery processor is augmented in the following 
way:

Statically known default collection type:       document()*
Statically known namespaces:                    The namespace declarations 
in-scope for the
                                                containing element or made 
available through
                                                p:namespaces.

The dynamic context used in evaluation the query is:

Context item:           document provided by the source-node port
Context position:       1
Context size:           1
Variable values:        The p:xquery parameters 
                        augment the variable bindings of the XQuery 
processor.
                        The parameter values are passed to the XQuery 
processor
                        as values of type xs:untypedAtomic.
Function implementations:       The function implementations provided by 
                                the XQuery processor.
Current dateTime:       implementation-defined value
Implicit timezone:      implementation-defined value
Available documents:    implementation-dependent
Available collections:  implementation-dependent
Default collection:     sequence of documents provided by the source port


5) 7.2.9 p:xquery, an example would be useful, editorial

Example:

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc">

<p:xinclude/>

<p:validate-with-xml-schema>
  <p:input port="schema">
    <p:document href="http://example.com/path/to/schema.xsd"/>
  </p:input>
</p:validate-with-xml-schema>

<p:query>
   <p:input port="query">
      <p:data href="file:countp.xq" />
   </p:input>
   <p:input port="source">
      <p:pipe step="validate-with-xml-schema" port="result"/>
   </p:input>
</p:query>

</p:pipeline>


Where countp.xq contains the following:

<count>{count(.//p)}</count>


                                                -- Andrew


[1] XProc: An XML Pipeline Language
http://www.w3.org/TR/2008/WD-xproc-20080814/


--------------------
Andrew Eisenberg
IBM
4 Technology Park Drive
Westford, MA  01886

andrew.eisenberg@us.ibm.com

Received on Monday, 22 September 2008 18:38:02 GMT

[+] [closed] Re: LCWD comments from XML Query and XSL WGs from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 12 Nov 2008 08:38:43 -0500
To: public-xml-processing-model-comments@w3.org
CC: Andrew Eisenberg <andrew.eisenberg@us.ibm.com>, Jim Melton <jim.melton@acm.org>, Sharon Adler <sca@us.ibm.com>
Message-ID: <m2abc59i8s.fsf@nwalsh.com>

Andrew Eisenberg <andrew.eisenberg@us.ibm.com> writes:

> The XML Query and XSL WGs approved the following comments on the XProc 
> LCWD [1] at our meeting on Sept. 16:
>
> 1) 2.6.2.2 Step XPath Context, minor technical
>
> Some of these items should specify that they are augmenting the values 
> provided by an implementation: Statically known namespaces, Default 
> element/type namespace, In-scope schema definitions, In-scope variables, 
> and Function signatures.
>
> An XPath implementation might provide some statically known namespaces, 
> for example, that are then augmented by those of p:namespaces, rather than 
> overwritten by them. 

Fixed.

> 2) 5.14 p:data, editorial
>
> Examples use p:file, rather than p:data.

Fixed.

> 3) 7.2.9 p:xquery, bulleted list beginning "The query port ...", editorial
>
> The 4th bullet does not recognize the third bullet. It should be changed 
> to "Otherwise, the interpretation of the query is implementation-defined."

Ok. Fixed.

> 4) 7.2.9 p:xquery, "The static context is augmented as follows:", minor 
> technical
>
> The static and dynamic context would be better stated independently of 
> section 2.6.2.2 Step XPath Context. That section is written rather 
> narrowly. It does not, for example, allow namespaces known a priori to the 
> XQuery implementation. We suggest the following:
>
> The static context of the XQuery processor is augmented in the following 
> way:
>
> Statically known default collection type:       document()*
> Statically known namespaces:                    The namespace declarations 
> in-scope for the
>                                                 containing element or made 
> available through
>                                                 p:namespaces.
>
> The dynamic context used in evaluation the query is:
>
> Context item:           document provided by the source-node port
> Context position:       1
> Context size:           1
> Variable values:        The p:xquery parameters 
>                         augment the variable bindings of the XQuery 
> processor.
>                         The parameter values are passed to the XQuery 
> processor
>                         as values of type xs:untypedAtomic.
> Function implementations:       The function implementations provided by 
>                                 the XQuery processor.
> Current dateTime:       implementation-defined value
> Implicit timezone:      implementation-defined value
> Available documents:    implementation-dependent
> Available collections:  implementation-dependent
> Default collection:     sequence of documents provided by the source port

It's not clear to me how this is substantially different from relying
on reference to 2.6.2.2, but we're happy to change the XQuery section
to satisfy the XQuery WG. Fixed.

> 5) 7.2.9 p:xquery, an example would be useful, editorial
>
> Example:
>
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
>
> <p:xinclude/>
>
> <p:validate-with-xml-schema>
>   <p:input port="schema">
>     <p:document href="http://example.com/path/to/schema.xsd"/>
>   </p:input>
> </p:validate-with-xml-schema>
>
> <p:query>
>    <p:input port="query">
>       <p:data href="file:countp.xq" />
>    </p:input>
>    <p:input port="source">
>       <p:pipe step="validate-with-xml-schema" port="result"/>
>    </p:input>
> </p:query>
>
> </p:pipeline>
>
> Where countp.xq contains the following:
>
> <count>{count(.//p)}</count>

Done.

We accepted all of your proposed changes, but if for some reason
you're unsatisfied with the result, please let us know. You can see
the changes now in the current editor's draft:

  http://www.w3.org/XML/XProc/docs/langspec.html#c.xquery

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A man's dying is more the survivors'
http://nwalsh.com/            | affair than his own.--Thomas Mann

Received on Wednesday, 12 November 2008 13:39:28 GMT

029.[+] p:wrap and group-adjacent from Norman Walsh on 21-Sep-2008

[+] Re: p:wrap and group-adjacent from mozer

[+] [closed] Re: p:wrap and group-adjacent from Norman Walsh

028.[+] simple rewording in 2.1 Steps from James Fuller on 20-Sep-2008

[+] [closed] Re: simple rewording in 2.1 Steps from Norman Walsh

027.[+] sync p:option and p:with-option from James Fuller on 19-Sep-2008

[+] Re: sync p:option and p:with-option from Norman Walsh

[+] [closed] Re: sync p:option and p:with-option from Norman Walsh

[+] Re: [closed] Re: sync p:option and p:with-option from James Fuller

026.[+] justify or remove aliases: base-uri, resolve-uri from Dan Connolly on 11-Sep-2008

[+] Re: justify or remove aliases: base-uri, resolve-uri from mozer

[+] Re: justify or remove aliases: base-uri, resolve-uri from Dan Connolly

[+] Re: justify or remove aliases: base-uri, resolve-uri from Henry S. Thompson

[+] Re: justify or remove aliases: base-uri, resolve-uri from Jeni Tennison

[+] Re: justify or remove aliases: base-uri, resolve-uri from Dan Connolly

[+] Re: justify or remove aliases: base-uri, resolve-uri from Henry S. Thompson

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 15 Sep 2008 14:55:38 +0100
To: Jeni Tennison <jeni@jenitennison.com>
Cc: public-xml-processing-model-comments@w3.org, Dan Connolly <connolly@w3.org>, mozer <xmlizer@gmail.com>
Message-ID: <f5bfxo1a4yt.fsf@hildegard.inf.ed.ac.uk>


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

Jeni Tennison writes:

> On 15 Sep 2008, at 09:54, Henry S. Thompson wrote:
>> Dan Connolly writes:
>>
>>> Whether they are aliases of XPath 1.0 or XPath 2.0 functions
>>> makes no difference; they're still aliases.
>>
>> I think perhaps you misunderstood.  There _is no_ XPath 1.0 function
>> which has the relevant behaviour.  So we have defined an extension
>> function _for XPath 1.0_ whose functionality is defined to be the
>> XPath 1.0 equivalent of an XPath 2.0 function.
>
>
> Perhaps Dan's point is that we should use the XPath 2.0 function
> namespace (http://www.w3.org/2005/xpath-functions) for those functions
> rather than co-opting them into our own namespace.

I thought of that, but that's sort of wrong, isn't it?  The function
we want is not actually/exactly the function whose name is
http://www.w3.org/2005/xpath-functions:base-uri, because that is a
function defined

  a) with input a node in an XPath 2 data model
 and
  b) value an xs:anyURI or NULL

whereas the function we are defining has 

  a) input an infoitem
 and
  b) output a string.

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)

iD8DBQFIzmlakjnJixAXWBoRAmLyAJwP/vTQX2vnUSYJ18O7QuW0N/6krwCbBK7g
j+9OSL4HvAkiiE/mTuG1jd8=
=kDfu
-----END PGP SIGNATURE-----

Received on Monday, 15 September 2008 13:56:27 GMT

[+] Re: justify or remove aliases: base-uri, resolve-uri from Dan Connolly

[+] Re: justify or remove aliases: base-uri, resolve-uri from Jeni Tennison

[+] Re: justify or remove aliases: base-uri, resolve-uri from Norman Walsh

[+] Re: justify or remove aliases: base-uri, resolve-uri from Dan Connolly

[+] [closed] Re: justify or remove aliases: base-uri, resolve-uri from Norman Walsh

025.[+] determining an xproc extension attributes from James Fuller on 01-Sep-2008

[+] Re: determining an xproc extension attributes from mozer

[+] Re: determining an xproc extension attributes from Norman Walsh

[+] Re: determining an xproc extension attributes from James Fuller

From: James Fuller <james.fuller.2007@gmail.com>
Date: Tue, 2 Sep 2008 17:49:04 +0200
Message-ID: <a0ad8ffe0809020849m61020713k4c5cadbb71ce1cf3@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org


I agree with both yours and Mohamed point ... and yes I have read
these sections a few times and understand how things are supposed to
work; I still think there is a contradiction between the 2 sections I
quoted.

J

On Tue, Sep 2, 2008 at 1:41 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> "James Fuller" <james.fuller.2007@gmail.com> writes:
>
>> in section 3.9 Syntax Summaries it states;
>>
>> 'It is a static error (err:XS0008) if any element in the XProc
>> namespace has attributes not defined by this specification unless they
>> are extension attributes.
>> '
>> then in section 3.8 Extension attributes it says;
>>
>> 'A processor which encounters an extension attribute that it does not
>> recognize must behave as if the attribute was not present.'
>>
>> Both of these statements seem to create a contradiction.
>>
>> How can a processor 'know' it is not recognizing an unknown extension
>> attribute ?
>
> Section 3.8, Extension Attributes, says:
>
> [Definition: An element from the XProc namespace may have any
> attribute not from the XProc namespace, provided that the
> expanded-QName of the attribute has a non-null namespace URI. Such an
> attribute is called an extension attribute.]
>
> Attributes in a namespace are extension attributes.
>
>                                        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 Tuesday, 2 September 2008 15:49:49 GMT

[+] Re: determining an xproc extension attributes from Henry S. Thompson

[+] Re: determining an xproc extension attributes from Norman Walsh

[+] Re: determining an xproc extension attributes from James Fuller

[+] [closed] Re: determining an xproc extension attributes from Norman Walsh

024.[+] p:option not required without default value from Innovimax SARL on 28-Aug-2008

[+] Re: p:option not required without default value from Norman Walsh

[+] Re: p:option not required without default value from Innovimax SARL

[+] Re: p:option not required without default value from Norman Walsh

[+] Re: p:option not required without default value from Henry S. Thompson

[+] Re: p:option not required without default value from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 29 Aug 2008 15:44:26 +0200
Message-ID: <546c6c1c0808290644o5401f4cev6e51011ddeeb2323@mail.gmail.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Cc: "Norman Walsh" <ndw@nwalsh.com>, public-xml-processing-model-wg@w3.org


Here is what XSLT 2.0 does

[[
If an optional parameter has no select  attribute and has an empty
sequence constructor, and if there is no as attribute, then the
default value of the parameter is a zero length string.
]]

Mohamed

On Fri, Aug 29, 2008 at 3:32 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Norman Walsh writes:
>
>> "Innovimax SARL" <innovimax@gmail.com> writes:
>>
>>> Nothing is said in the spec about what to do if we have the following
>>> pipeline
>>>
>>> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" xmlns:ix="
>>> http://www.innovimax.fr/ns">
>>>     <p:declare-step type="ix:test">
>>>         <p:input port="source"/>
>>>         <p:output port="result"/>
>>>         <p:option name="not-required-no-default"/>
>>>         <p:choose>
>>>             <p:when test="$not-required-no-default">
>>>                 <p:identity/>
>>>             </p:when>
>>>             <p:otherwise>
>>>                 <p:filter select="/*"/>
>>>             </p:otherwise>
>>>         </p:choose>
>>>     </p:declare-step>
>>>     <ix:test/>
>>> </p:pipeline>
>>
>> You're right. That either has to be an error or we have to specify what
>> the default default value for options.
>
> The empty node set.  That way testing it will fail, which is surely
> what you want.
>
> Hmm.  Problem is that there is no XPath equivalent of 'boundp'. . .
>
> I can see arguments either way.  Flbssst. . .
>
> 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 650-4587, 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)
>
> iD8DBQFIt/pQkjnJixAXWBoRAum3AJ0RrJN3NyK7wyntd/kvKKHMQMR/8ACfROCi
> fVdf9UuN8SazooZv1XaEwTk=
> =b9vF
> -----END PGP SIGNATURE-----
>
>



-- 
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 Friday, 29 August 2008 13:45:04 GMT

[+] Re: p:option not required without default value from Henry S. Thompson

[+] Re: p:option not required without default value from Innovimax SARL

[+] Re: p:option not required without default value from Jeni Tennison

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 29 Aug 2008 21:23:32 +0100
Message-Id: <BB2D5873-C6A5-40D0-9F97-F73EAD4EAA47@jenitennison.com>
To: public-xml-processing-model-wg WG <public-xml-processing-model-wg@w3.org>

On 29 Aug 2008, at 18:41, Innovimax SARL wrote:
> 1) We forbid to have an option that has no default and is not bound
> 2) We propose a default value
>  2a) A default value that generate an error (which seems impossible
> since string() always succeed)
>  2b) The default is the empty string
>
> If we go with 1), then we should get rid of @required, since if you
> provide a default value, it cannot be required, and if there is no
> @select, then it is required
>
> If we go 2) then we stick to XSLT 1.0 and 2.0 behaviour (for good or  
> bad)

I think we will have more flexibility in the future (should we want to  
provide a good default default value such as an empty sequence, when/ 
if options are allowed to take values other than strings) if we don't  
fix a default default of an empty string.

Looking through the required steps, there are quite a few optional,  
"undefaulted" options. Most of them could be given a reasonable  
default but an empty string wouldn't be legal (eg 'node()|@*' would be  
reasonable for match patterns, but an empty string wouldn't be legal).

There are a few where it's harder. For example, the default value of  
'media-type' on p:escape-markup is dependent on the 'method'. Perhaps  
that just means it should be declared (after the declaration of the  
'method' option) as:

   <p:option name="media-type"
     select="if ($method = 'xml') then 'application/xml'
             else if ($method = 'xhtml') then 'application/xhtml+xml'
             else if ($method = 'html') then 'text/html'
             else 'text/plain'" />

However, putting logic in the default value of an option doesn't make  
sense when you're declaring an atomic step, where presumably the  
option defaults are defined by the processor rather than the step  
declaration. So what about:

   * in the declaration of an atomic step
     * the required attribute is used to indicate whether the option  
is required or not
     * the select attribute may be used to declare a default value; if  
it's not specified the default is implementation-defined

   * in the declaration of a pipeline
     * if the select attribute is present, it's used as a default  
value (and required must be 'no')
     * if the select attribute is not present, required must be 'yes',  
and defaults to that value if it's not specified

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 29 August 2008 20:24:10 GMT

[+] Re: p:option not required without default value from Innovimax SARL

[+] Re: p:option not required without default value from Jeni Tennison

[+] Re: p:option not required without default value from Innovimax SARL

[+] [closed] Re: p:option not required without default value from Norman Walsh

023.[+] p:pipe convention from James Fuller on 26-Aug-2008

[+] [closed] Re: p:pipe convention from Norman Walsh

[+] Re: [closed] Re: p:pipe convention from James Fuller

022.[+] clarify the difference of usage of p:input in section 5.1.1. from James Fuller on 26-Aug-2008

[+] Re: clarify the difference of usage of p:input in section 5.1.1. from Norman Walsh

[+] [closed] Re: clarify the difference of usage of p:input in section 5.1.1. from Norman Walsh

021.[+] foreign namespaces from James Fuller on 26-Aug-2008

[+] Re: foreign namespaces from Norman Walsh

[+] Re: foreign namespaces from James Fuller

[+] Re: foreign namespaces from Norman Walsh

[+] Re: foreign namespaces from Florent Georges

[+] Re: foreign namespaces from mozer

[+] Re: foreign namespaces from James Fuller

[+] Re: foreign namespaces from mozer

[+] Re: foreign namespaces from James Fuller

[+] Re: foreign namespaces from Florent Georges

[+] Re: foreign namespaces from Norman Walsh

[+] Re: foreign namespaces from Florent Georges

[+] Re: foreign namespaces from Norman Walsh

[+] Re: foreign namespaces from Florent Georges

[+] Re: foreign namespaces from James Fuller

[+] Re: foreign namespaces from Norman Walsh

[+] [closed] Re: foreign namespaces from Norman Walsh

[+] Re: [closed] Re: foreign namespaces from James Fuller

020.[+] p:encrypt and p:decrypt from James Fuller on 26-Aug-2008

[+] Re: p:encrypt and p:decrypt from Norman Walsh

[+] [closed] Re: p:encrypt and p:decrypt from Norman Walsh

019.[+] Format of hashed values from Norman Walsh on 23-Aug-2008

[+] Re: Format of hashed values from Innovimax SARL

[+] Re: Format of hashed values from Norman Walsh

[+] Re: Format of hashed values from Innovimax SARL

[+] [closed] Re: Format of hashed values from Norman Walsh

018.[+] Names for p:* steps from Norman Walsh on 21-Aug-2008

[+] Re: Names for p:* steps from Innovimax SARL

[+] Re: Names for p:* steps from Norman Walsh

[+] Re: Names for p:* steps from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 22 Aug 2008 16:19:12 +0200
Message-ID: <546c6c1c0808220719h55594a9r5c7127b5925a7518@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org


On Fri, Aug 22, 2008 at 3:45 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> "Innovimax SARL" <innovimax@gmail.com> writes:
>
>> Well, may I ask you to elaborate on this ?
>
> Sure.
>
> Imagine that library.xpl contains:
>
>  <p:library ...>
>    <p:declare-step name="xinclude-and-xslt">...</p:declare-step>
>  </p:library>
>
> Consider the following imaginary command line syntax:
>
> $ calabash -isource=- -oresult=- -s xinclude-and-xslt library.xpl
>
> This tells the processor to load "library.xpl" and run the step named
> "xinclude-and-xslt". All straightforward.
>
> Now suppose I want to just run the "add-attribute" step. I could wrap
> it in a pipeline, put it in a library, give it a name, and run it. But
> since the library for the XProc builtin steps is always loaded (at
> least conceptually), why do I have to do that? Why can't I just say:
>
> $ calabash -isource=- -oresult=- -s add-attribute \
>          match=div attribute-name=foo attribute-value=bar
>
> I can't because the standard p:add-attribute step doesn't have a name.
>
> I was wondering if we couldn't do something about that. But I don't
> think we can.
>
> However, I think I'll work around the problem by saying that if you
> don't load a pipeline or a library and if you specify a step name then
> the xml:id values of the standard steps are considered for the purpose
> of matching the specified name.

Sorry for the comparison, but you remind me someone 10 years ago,
asking me why we can't execute any Java class that was in the JDK

I still think that declare step is declaring abstract model of the step

so if you want to instantiate it, I would say that you need to provide
a other mode to launch an abstract

 $ calabash -isource=- -oresult=- -instantiate p:add-attribute \
          match=div attribute-name=foo attribute-value=bar

where -instantiate takes a type instead of name and instantiate an
anonymous instance of that type

Mohamed
-- 
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 Friday, 22 August 2008 14:19:49 GMT

[+] Re: Names for p:* steps from Norman Walsh

[+] RE: Names for p:* steps from Toman_Vojtech@emc.com

[+] Re: Names for p:* steps from Norman Walsh

[+] Re: Names for p:* steps from Jeni Tennison

[+] Re: Names for p:* steps from Norman Walsh

[+] [closed] Re: Names for p:* steps from Norman Walsh

017.[+] Re: UUID : add reference from Innovimax SARL on 21-Aug-2008

[+] Re: UUID : add reference from Norman Walsh

[+] Re: UUID : add reference from Innovimax SARL

[+] [closed] Re: UUID : add reference from Norman Walsh

016.[+] Re: Kind of node matched from Innovimax SARL on 21-Aug-2008

[+] RE: Kind of node matched from Toman_Vojtech@emc.com

From: <Toman_Vojtech@emc.com>
Date: Fri, 22 Aug 2008 02:15:58 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870C4E7016@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-wg@w3.org>

I think we have already discussed this one:

http://www.w3.org/XML/XProc/2008/06/05-minutes.html#item04


Regards,
Vojtech

> 
> Rethrowing this mail
> 
> On Sat, May 3, 2008 at 9:28 AM, Innovimax SARL 
> <innovimax@gmail.com> wrote:
> > Each of the following step uses a match option which is 
> XSLTMatchPattern
> >
> > As such, it could match different kind of node amongst the 
> following :
> > * comment
> > * text
> > * processing-instruction
> > * element node
> > * attribute node
> > ** (in theory also namespace node but let's keep the 
> discussion separate for
> > the moment)
> >
> >
> > == ONLY ELEMENT NODE ==
> >
> > * 4.3 p:viewport
> >
> > * 7.1.1 p:add-attribute
> >
> > * 7.1.11 p:insert (when position is 'first-child' or 'last-child')
> >
> > * 7.1.12 p:label-elements
> >
> > * 7.1.20 p:set-attributes
> >
> > * 7.1.26 p:unwrap
> >
> > == ONLY ELEMENT NODE OR ATTRIBUTE NODE ==
> >
> > * 7.1.14 p:make-absolute-uris
> >
> > == EVERY KIND OF NODE ==
> >
> > * 7.1.5 p:delete
> >
> > * 7.1.24 p:string-replace
> >
> > * 7.2.3 p:uuid
> >
> > * 7.2.8 p:www-form-urlencode
> >
> > == ONLY COMMENT, TEXT, PROCESSING-INSTRUCTION and ELEMENT 
> NODE (a.k.a NO
> > ATTRIBUTE)==
> >
> > * 7.1.11 p:insert (when position is 'before' or 'after')
> >
> > * 7.1.19 p:replace
> >
> > * 7.1.27 p:wrap
> >
> >
> > == ONLY PROCESSING-INSTRUCTION, ELEMENT NODE and ATTRIBUTE 
> NODE (a.k.a
> > NAMED) ==
> >
> > * 7.1.18 p:rename
> >
> > What do you think of such categorisation ?
> >
> > --
> > 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 €
> 
> 
> 
> -- 
> 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 Friday, 22 August 2008 06:16:47 GMT

[+] Re: Kind of node matched from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 22 Aug 2008 08:35:19 +0200
Message-ID: <546c6c1c0808212335j7a3a9bbfmb5950754fe6e58a1@mail.gmail.com>
To: Toman_Vojtech@emc.com
Cc: public-xml-processing-model-wg@w3.org


Thanks Vojtech,

It means it's in Norm's hands

On Fri, Aug 22, 2008 at 8:15 AM,  <Toman_Vojtech@emc.com> wrote:
> I think we have already discussed this one:
>
> http://www.w3.org/XML/XProc/2008/06/05-minutes.html#item04
>
> Regards,
> Vojtech
>
>>
>> Rethrowing this mail
>>
>> On Sat, May 3, 2008 at 9:28 AM, Innovimax SARL
>> <innovimax@gmail.com> wrote:
>> > Each of the following step uses a match option which is
>> XSLTMatchPattern
>> >
>> > As such, it could match different kind of node amongst the
>> following :
>> > * comment
>> > * text
>> > * processing-instruction
>> > * element node
>> > * attribute node
>> > ** (in theory also namespace node but let's keep the
>> discussion separate for
>> > the moment)
>> >
>> >
>> > == ONLY ELEMENT NODE ==
>> >
>> > * 4.3 p:viewport
>> >
>> > * 7.1.1 p:add-attribute
>> >
>> > * 7.1.11 p:insert (when position is 'first-child' or 'last-child')
>> >
>> > * 7.1.12 p:label-elements
>> >
>> > * 7.1.20 p:set-attributes
>> >
>> > * 7.1.26 p:unwrap
>> >
>> > == ONLY ELEMENT NODE OR ATTRIBUTE NODE ==
>> >
>> > * 7.1.14 p:make-absolute-uris
>> >
>> > == EVERY KIND OF NODE ==
>> >
>> > * 7.1.5 p:delete
>> >
>> > * 7.1.24 p:string-replace
>> >
>> > * 7.2.3 p:uuid
>> >
>> > * 7.2.8 p:www-form-urlencode
>> >
>> > == ONLY COMMENT, TEXT, PROCESSING-INSTRUCTION and ELEMENT
>> NODE (a.k.a NO
>> > ATTRIBUTE)==
>> >
>> > * 7.1.11 p:insert (when position is 'before' or 'after')
>> >
>> > * 7.1.19 p:replace
>> >
>> > * 7.1.27 p:wrap
>> >
>> >
>> > == ONLY PROCESSING-INSTRUCTION, ELEMENT NODE and ATTRIBUTE
>> NODE (a.k.a
>> > NAMED) ==
>> >
>> > * 7.1.18 p:rename
>> >
>> > What do you think of such categorisation ?
>> >
>> > --
>> > 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 €
>>
>>
>>
>> --
>> 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 €
>>
>>
>>
>



-- 
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 Friday, 22 August 2008 06:35:54 GMT

[+] Re: Kind of node matched from Norman Walsh

[+] Re: Kind of node matched from Innovimax SARL

[+] ACTION-2008-08-28-03: the kinds of nodes that are legal for all steps from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 23 Sep 2008 08:32:01 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2vdwnyrem.fsf@nwalsh.com>

N.B. There are two change proposals herein.

We begin with the general rule in 7.0:

  In most steps which use a select expression or match pattern, any
  kind of node can be identified by the expression or pattern.
  However, some expressions and patterns on some steps are only
  applicable to some kinds of nodes (e.g., it doesn't make sense to
  speak of adding attributes to a comment!).

  It is a dynamic error (err:XC0023) if a select expression or match
  pattern returns a node type that is not allowed by the step.

The consider each of the steps in turn:

7.1.1 p:add-attribute

Must match an element and says so.

7.1.2 p:add-xml-base
7.1.3 p:compare
7.1.4 p:count
Have no select/match attribute.

7.1.5 p:delete

Can match any kind of node, so the general rule applies.

7.1.6 p:directory-list
7.1.7 p:error
7.1.8 p:escape-markup

Have no select/match attribute.

7.1.9 p:filter

Must identify an element and says so by reference to the semantics of
select on p:input.

7.1.10 p:http-request
7.1.11 p:identity

Have no select/match attribute

7.1.12 p:insert

Allows only element nodes and says so. On reflection, I think this is
correct. On some call we had a discussion about the possibility of
inserting, for example, comments before the document element. It turns
out that this isn't possible because the content to be inserted must
be a document and must, therfore, contain an element.

7.1.13 p:label-elements

Must match elements and says so.

7.1.14 p:load

Has no select/match attribute.

7.1.15 p:make-absolute-uris

Must match element or attribute nodes and says so.

7.1.16 p:namespace-rename
7.1.17 p:pack
7.1.18 p:parameters

Have no select/match attribute.

7.1.19 p:rename

Must match element, attribute, or processing instruction nodes and says so.

7.1.20 p:replace

Claims that it must match element nodes, but I don't see why.

PROPOSAL: Allow the match pattern to match element, comment,
processing-instruction, or text nodes.

7.1.21 p:set-attributes

Must match element nodes and says so.

7.1.22 p:sink
7.1.23 p:split-sequence
7.1.24 p:store

Have no select/match attribute.

7.1.25 p:string-replace

Can match any kind of node and says so.

7.1.26 p:unescape-markup

Has no select/match attribute.

7.1.27 p:unwrap

Must match element nodes and says so.

7.1.28 p:wrap

Can match element, text, processing instruction, and comment nodes and
says so.

The current text makes group-adjacent meaningless unless element nodes
are matched.

PROPOSAL: Change the description of adjacency as follows:

  Two matching nodes are considered adjacent if and only if they are
  siblings and only ignorable nodes occur between them.

  If both matching nodes are elements, then whitespace text, comment,
  and processing instruction nodes are ignorable.

  If either matching node is not an element, then only whitespace text
  nodes are ignorable.

7.1.29 p:wrap-sequence
7.1.30 p:xinclude
7.1.31 p:xslt
7.2.1 p:exec

Have no select/match attribute.

7.2.2 p:hash
7.2.3 p:uuid

Can match any kind of node and says so.

7.2.4 p:validate-with-relax-ng
7.2.5 p:validate-with-schematron
7.2.6 p:validate-with-xml-schema
7.2.7 p:www-form-urldecode

Have no select/match attribute.

7.2.8 p:www-form-urlencode

Can match any kind of node and says so.

7.2.9 p:xquery
7.2.10 p:xsl-formatter

Have no select/match attribute.

========================================

Mohamed made two other proposals in LC 016:

- That match on p:viewport can only match element nodes. This is true, but
  I don't think we have to say anything else because the text is clear that
  the matched nodes are treated as documents, so they must be elements.

- Proposal to change p:insert, but I don't think that works for the reasons
  I cited above.

I think that *at last* discharges my action!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | There is nothing new under the sun but
http://nwalsh.com/            | there are lots of old things we don't
                              | know.--Ambrose Bierce

Received on Tuesday, 23 September 2008 12:32:53 GMT

[+] Re: ACTION-2008-08-28-03: the kinds of nodes that are legal for all steps from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Wed, 24 Sep 2008 17:00:28 +0200
Message-ID: <546c6c1c0809240800y340d39b7j7bcfabbfd7cb0795@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org

On Tue, Sep 23, 2008 at 2:32 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> N.B. There are two change proposals herein.
>
> 7.1.12 p:insert
>
> Allows only element nodes and says so. On reflection, I think this is
> correct. On some call we had a discussion about the possibility of
> inserting, for example, comments before the document element. It turns
> out that this isn't possible because the content to be inserted must
> be a document and must, therfore, contain an element.
>
>
> 7.1.20 p:replace
>
> Claims that it must match element nodes, but I don't see why.
>
> PROPOSAL: Allow the match pattern to match element, comment,
> processing-instruction, or text nodes.


OK


>
>
>
>
>
> The current text makes group-adjacent meaningless unless element nodes
> are matched.
>
> PROPOSAL: Change the description of adjacency as follows:
>
>  Two matching nodes are considered adjacent if and only if they are
>  siblings and only ignorable nodes occur between them.
>
>  If both matching nodes are elements, then whitespace text, comment,
>  and processing instruction nodes are ignorable.
>
>  If either matching node is not an element, then only whitespace text
>  nodes are ignorable.


Seems ok at first glance


>
>
> ========================================
>
> Mohamed made two other proposals in LC 016:
>
> - That match on p:viewport can only match element nodes. This is true, but
>  I don't think we have to say anything else because the text is clear that
>  the matched nodes are treated as documents, so they must be elements.
>

ok that's fine

>
> - Proposal to change p:insert, but I don't think that works for the reasons
>  I cited above.
>

Well I don't agree
What about Richard argument in http://www.w3.org/XML/XProc/2008/08/28-
minutes
[[
I like Richard's formulation: p:insert allows matching of anything
  which may have children if where is first or last, and anything that _is_
  a child if where is before or after
]]

>
> I think that *at last* discharges my action!






-- 
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, 24 September 2008 15:01:05 GMT

[+] Re: ACTION-2008-08-28-03: the kinds of nodes that are legal for all steps from Norman Walsh

[+] Re: ACTION-2008-08-28-03: the kinds of nodes that are legal for all steps from Innovimax SARL

[+] [closed] Re: Kind of node matched from Norman Walsh

015.[+] Re: add p:encrypt and p:decrypt optional step from Innovimax SARL on 21-Aug-2008

[+] Re: add p:encrypt and p:decrypt optional step from Norman Walsh

[+] Re: add p:encrypt and p:decrypt optional step from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 22 Aug 2008 16:05:27 +0200
Message-ID: <546c6c1c0808220705q349c6a25v68b75b0ce9c965c5@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org


There are still all sorts of token and seed and certificates, but
that's what parameters are for

I think we should not try to be too clever

If afterwards we see some possible rationnalisation, then we would be
able to add optionals options to the signature in V.next

Mohamed

On Fri, Aug 22, 2008 at 3:35 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> "Innovimax SARL" <innovimax@gmail.com> writes:
>
>> We could say that we have
>>
>> <p:declare-step type="p:encrypt">
>>    <p:input port="source" primary="true"/>
>>    <p:output port="result"/>
>>    <p:input port="parameters" kind="parameter"/>
>>    <p:option name="match" required="true"/> <!-- XSLTMatchPattern -->
>>   <p:option name="granularity" required="true"/><!-- 'content' or 'element'
>> -->
>> </p:declare-step>
>>
>> match option would say which elements you want to encrypt and granularity
>> option would say if you encrypt the matched element or its content
>
> Is that all you need to do encryption? Everytime I've tried to
> understand XMLDSig kits there's been all sorts of stuff about tokens
> and certificates that I've never been able to get my head around.
>
>> <p:declare-step type="p:decrypt">
>>    <p:input port="source" primary="true"/>
>>    <p:output port="result"/>
>>    <p:input port="parameters" kind="parameter"/>
>>    <p:option name="match" required="true"/> <!-- XSLTMatchPattern -->
>> </p:declare-step>
>>
>> match would match perticular node
>> {http://www.w3.org/2001/04/xmlenc#}EncryptedData (if we stick to XML
>> Encryption spec, but we don't need to) and would decrypt them
>
> Again, is there enough information here to do the job?
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | First time surrealists are often
> http://nwalsh.com/            | confused by the similarities between
>                              | fish and telephones.
>



-- 
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 Friday, 22 August 2008 14:06:06 GMT

[+] Re: add p:encrypt and p:decrypt optional step from Norman Walsh

[+] [closed] Re: add p:encrypt and p:decrypt optional step from Norman Walsh

014.[+] (still few) troubles with p:namespaces from Innovimax SARL on 21-Aug-2008

From: Innovimax SARL <innovimax@gmail.com>
Date: Thu, 21 Aug 2008 14:20:22 +0200
Message-ID: <546c6c1c0808210520wef1f114nf9174057d16ca632@mail.gmail.com>
To: "XProc WG" <public-xml-processing-model-wg@w3.org>


I have still trouble to fully understand the code fragment provided as
sample in the spec

Especially this one

[[
<p:pipeline type="ex:delete-in-div"
            xmlns:p="http://www.w3.org/ns/xproc"
            xmlns:ex="http://example.org/ns/ex"
            xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="divchild" required="true"/>

<p:delete>
  <p:with-option name="match" select="concat('h:div/',$divchild)">
    <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml"
                  xmlns:html="http://www.w3.org/1999/xhtml"/>
  </p:with-option>
</p:delete>

</p:pipeline>
]]

In my understanding, the binding of the prefix "h" has been done on
p:pipeline element, so we don't need to recall the binding on
p:namespaces element, do we ?

Furthermore again by the same rule ("Otherwise, the in-scope
namespaces from the element providing the value are used."), we can
completely get rid of p:namespaces in this case

<p:delete>
  <p:with-option name="match" select="concat('h:div/',$divchild)"
xmlns:html="http://www.w3.org/1999/xhtml"/>
</p:delete>

Am I right ?

Hence we got also
[[
<?xml version='1.0'?>
<p:pipeline type="ex:delete-in-div"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:ex="http://example.org/ns/ex"
xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="divchild" required="true"/>

<p:delete>
  <p:with-option name="match" select="concat('h:div/',$divchild)">
    <p:namespaces binding="divchild"/><!-- this one makes full sense for me -->
  </p:with-option>
</p:delete>

</p:pipeline>
]]

Mohamed
-- 
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 Thursday, 21 August 2008 12:20:57 GMT

[+] RE: (still few) troubles with p:namespaces from Toman_Vojtech@emc.com

[+] [closed] Re: (still few) troubles with p:namespaces from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 17 Sep 2008 07:15:20 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2abe7f2gn.fsf@nwalsh.com>

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

> I have still trouble to fully understand the code fragment provided as
> sample in the spec
>
> Especially this one
>
> [[
> <p:pipeline type="ex:delete-in-div"
>             xmlns:p="http://www.w3.org/ns/xproc"
>             xmlns:ex="http://example.org/ns/ex"
>             xmlns:h="http://www.w3.org/1999/xhtml">
> <p:option name="divchild" required="true"/>
>
> <p:delete>
>   <p:with-option name="match" select="concat('h:div/',$divchild)">
>     <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml"
>                   xmlns:html="http://www.w3.org/1999/xhtml"/>
>   </p:with-option>
> </p:delete>
>
> </p:pipeline>
> ]]
>
> In my understanding, the binding of the prefix "h" has been done on
> p:pipeline element, so we don't need to recall the binding on
> p:namespaces element, do we ?

No, I suppose not, since it's already in-scope. But it's not wrong
to put it there and it does make the intent explicit. Still, it might
mislead someone into thinking that p:namespaces uses only the *declared*
namespaces not the in-scope ones, so I'll remove xmlns:h.

> Furthermore again by the same rule ("Otherwise, the in-scope
> namespaces from the element providing the value are used."), we can
> completely get rid of p:namespaces in this case
>
> <p:delete>
>   <p:with-option name="match" select="concat('h:div/',$divchild)"
> xmlns:html="http://www.w3.org/1999/xhtml"/>
> </p:delete>
>
> Am I right ?

Yes, you could do that. This example is really just a setup ("here's
how you *could* do it") for the next example ("here's how you *should*
do it").

On further reflection, I'm happy with these examples as they stand.
However, I'll add a note to point out that it's not strictly
necessary.

> Hence we got also
> [[
> <?xml version='1.0'?>
> <p:pipeline type="ex:delete-in-div"
> xmlns:p="http://www.w3.org/ns/xproc"
> xmlns:ex="http://example.org/ns/ex"
> xmlns:h="http://www.w3.org/1999/xhtml">
> <p:option name="divchild" required="true"/>
>
> <p:delete>
>   <p:with-option name="match" select="concat('h:div/',$divchild)">
>     <p:namespaces binding="divchild"/><!-- this one makes full sense for me -->

Here you *do* need the second p:namespaces element with the xmlns:h binding.
Otherwise you won't have one because:

   If a p:variable, p:with-option or p:with-param includes one or more
   p:namespaces elements, then the union of all the namespaces
   specified on those elements are used as the bindings for the
   variable, option or parameter value. In this case, the in-scope
   namespaces on the p:variable, p:with-option or p:with-param are
   ignored.

and 

   If the binding attribute is specified, it must contain the name of a
   single in-scope binding. The namespace bindings associated with that
   binding are used.

Since divchild is specified in a context where xmlns:h isn't bound, it wouldn't
otherwise be bound.

>   </p:with-option>
> </p:delete>
>
> </p:pipeline>
> ]]

I've made a few editorial corrections, please let us know if you're
unsatisfied with the result.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The richness of life lies in memories
http://nwalsh.com/            | we have forgotten.--Cesare Pavese

Received on Wednesday, 17 September 2008 11:16:22 GMT

[+] Re: [closed] Re: (still few) troubles with p:namespaces from Innovimax SARL

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 19 Sep 2008 09:24:12 +0200
Message-ID: <546c6c1c0809190024wa5f80cbs9732cf720844357c@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org

Norm,

Do you mean the spec at http://www.w3.org/XML/XProc/docs/langspec.html
has changed ?

It is still dated from August 21

Regards,

Mohamed

On Wed, Sep 17, 2008 at 1:15 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> "Innovimax SARL" <innovimax@gmail.com> writes:
>
> > I have still trouble to fully understand the code fragment provided as
> > sample in the spec
> >
> > Especially this one
> >
> > [[
> > <p:pipeline type="ex:delete-in-div"
> >             xmlns:p="http://www.w3.org/ns/xproc"
> >             xmlns:ex="http://example.org/ns/ex"
> >             xmlns:h="http://www.w3.org/1999/xhtml">
> > <p:option name="divchild" required="true"/>
> >
> > <p:delete>
> >   <p:with-option name="match" select="concat('h:div/',$divchild)">
> >     <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml"
> >                   xmlns:html="http://www.w3.org/1999/xhtml"/>
> >   </p:with-option>
> > </p:delete>
> >
> > </p:pipeline>
> > ]]
> >
> > In my understanding, the binding of the prefix "h" has been done on
> > p:pipeline element, so we don't need to recall the binding on
> > p:namespaces element, do we ?
>
> No, I suppose not, since it's already in-scope. But it's not wrong
> to put it there and it does make the intent explicit. Still, it might
> mislead someone into thinking that p:namespaces uses only the *declared*
> namespaces not the in-scope ones, so I'll remove xmlns:h.
>
> > Furthermore again by the same rule ("Otherwise, the in-scope
> > namespaces from the element providing the value are used."), we can
> > completely get rid of p:namespaces in this case
> >
> > <p:delete>
> >   <p:with-option name="match" select="concat('h:div/',$divchild)"
> > xmlns:html="http://www.w3.org/1999/xhtml"/>
> > </p:delete>
> >
> > Am I right ?
>
> Yes, you could do that. This example is really just a setup ("here's
> how you *could* do it") for the next example ("here's how you *should*
> do it").
>
> On further reflection, I'm happy with these examples as they stand.
> However, I'll add a note to point out that it's not strictly
> necessary.
>
> > Hence we got also
> > [[
> > <?xml version='1.0'?>
> > <p:pipeline type="ex:delete-in-div"
> > xmlns:p="http://www.w3.org/ns/xproc"
> > xmlns:ex="http://example.org/ns/ex"
> > xmlns:h="http://www.w3.org/1999/xhtml">
> > <p:option name="divchild" required="true"/>
> >
> > <p:delete>
> >   <p:with-option name="match" select="concat('h:div/',$divchild)">
> >     <p:namespaces binding="divchild"/><!-- this one makes full sense for
> me -->
>
> Here you *do* need the second p:namespaces element with the xmlns:h
> binding.
> Otherwise you won't have one because:
>
>   If a p:variable, p:with-option or p:with-param includes one or more
>   p:namespaces elements, then the union of all the namespaces
>   specified on those elements are used as the bindings for the
>   variable, option or parameter value. In this case, the in-scope
>   namespaces on the p:variable, p:with-option or p:with-param are
>   ignored.
>
> and
>
>   If the binding attribute is specified, it must contain the name of a
>   single in-scope binding. The namespace bindings associated with that
>   binding are used.
>
> Since divchild is specified in a context where xmlns:h isn't bound, it
> wouldn't
> otherwise be bound.
>
> >   </p:with-option>
> > </p:delete>
> >
> > </p:pipeline>
> > ]]
>
> I've made a few editorial corrections, please let us know if you're
> unsatisfied with the result.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | The richness of life lies in memories
> http://nwalsh.com/            | we have forgotten.--Cesare Pavese
>



-- 
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 Friday, 19 September 2008 07:24:56 GMT

[+] Re: [closed] Re: (still few) troubles with p:namespaces from Norman Walsh

013.[+] Re: what about option values on directly invoked p:declare-step from Norman Walsh on 21-Aug-2008

[+] [closed] Re: what about option values on directly invoked p:declare-step from Norman Walsh

012.[+] Re: more PSVI from Norman Walsh on 21-Aug-2008

[+] [closed] Re: more PSVI from Norman Walsh

[+] Re: [closed] Re: more PSVI from James Fuller

From: James Fuller <james.fuller.2007@gmail.com>
Date: Wed, 17 Sep 2008 12:39:10 +0200
Message-ID: <a0ad8ffe0809170339h7175d15cn7995c4e9674fc0a0@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org


thx, sounds good to me

On Wed, Sep 17, 2008 at 12:37 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> Norman Walsh <ndw@nwalsh.com> writes:
>
>> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
>> | thx goes to MohamedZ for pointing out the current WG debate as I had
>> | my own PSVI questions.
>> |
>> | a few ruminations on PSVI;
>> |
>> | * what if we want to preserve PSVI annotations through a step that
>> | does not require it ? e.g. something like a psvi-passthru attribute
>> | though perhaps all this is a bit cumbersome for corner case?
>>
>> Most of the steps can change the structure of a document. That could
>> make any of the PSVI properties invalid. I think it's better to say
>> you have to (re)validate after you run those steps.
>>
>> | * what happens when p:xslt is using a validating XSLT v2.0 does the
>> | existing psvi-required attribute need to be set to true then ?
>>
>> I think the behavior in the absence of @psvi-required is
>> implementation-defined. The XSLT step is always free to produce PSVI
>> annotations. You only need to put @psvi-required on the step that
>> *consumes* XSLT output if you want to be sure that the implementation
>> kept them.
>
> The WG has considered this issue and concluded that only the following
> editorial change was necessary to address it:
>
> <note>
> <para>A processor that supports passing PSVI properties between steps
> is always free to do so. Even if
> <code>psvi-required="false"</code> is explicitly specified, it is not
> an error for a step to produce a result that includes additional PSVI
> properties, provide it does not violate the constraints above.</para>
> </note>
>
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | Everything the same; everything
> http://nwalsh.com/            | distinct.
>

Received on Wednesday, 17 September 2008 10:39:46 GMT

011.[+] Side question : p:documentation and p:pipeinfo inside c:* elements from Innovimax SARL on 20-Aug-2008

[+] [closed] Re: Side question : p:documentation and p:pipeinfo inside c:* elements from Norman Walsh

010.[+] Correction in relax ng compact model from Innovimax SARL on 20-Aug-2008

[+] [closed] Re: Correction in relax ng compact model from Norman Walsh

009.[+] Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Innovimax SARL on 20-Aug-2008

[+] Re: Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Innovimax SARL

[+] Re: Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Norman Walsh

[+] RE: Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Toman_Vojtech@emc.com

[+] Re: Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Innovimax SARL

[+] [closed] Re: Quirks in code fragment of 5.7.5 Namespaces on variables, options, and parameters from Norman Walsh

008.[+] XProc comment from Alex Brown on 20-Aug-2008

[+] Re: XProc comment from Norman Walsh

[+] [closed] Re: XProc comment from Norman Walsh

007.[+] p:data and error codes from Toman_Vojtech@emc.com on 18-Aug-2008

[+] Re: p:data and error codes from Norman Walsh

[+] RE: p:data and error codes from Toman_Vojtech@emc.com

[+] [closed] Re: p:data and error codes from Norman Walsh

006.[+] The 'content-type' attribute is not optional on c:data from Toman_Vojtech@emc.com on 18-Aug-2008

[+] [closed] Re: The 'content-type' attribute is not optional on c:data from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 21 Aug 2008 07:36:45 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2r68izjjm.fsf@nwalsh.com>

/ Toman_Vojtech@emc.com was heard to say:
| Hi all,
|
| I am a bit confused by the text about the content-type attribute in
| section 5.14 (p:data). The text contains the following sentences:
|
| "If no wrapper element is specified, the default is c:data"
| "The wrapper element should have a content-type attribute"
| "If a content-type attribute is specified on a c:data wrapper, ..."
|
| But, since @content-type is not optional in c:data, I don't think these
| sentences work together very well.

I think that's the bug. I've made content-type optional on c:data (it's
only a SHOULD in the spec.)

| If I remember it correctly, c:data was originally only used in p:xquery,
| where it was required to always specify a content type (the p:xquery
| section still says: "If the document root element is c:data or has a
| c:content-type attribute that specifies..."). 
|
| I think we should either make @content-type optional in c:data (which
| could make problems in p:xquery) or reword the text about p:data in such

I don't think it makes any problems for XQuery. If you use c:data and pass
some binary resource (which will be base64 encoded), your query will fail.
But that's a feature not a bug :-)

| a way that is mandates that @content-type must be specified if c:data is
| used. I am not sure which option is better/worse, though.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In the life of saints, technically so
http://nwalsh.com/            | called, the spiritual facilities are
                              | strong, but what gives the impression
                              | of extravagance proves usually on
                              | examination to be a relative deficiency
                              | of intellect.--William James

Received on Thursday, 21 August 2008 11:38:03 GMT

005.[+] Examples for p:data are still using p:file from Toman_Vojtech@emc.com on 18-Aug-2008

[+] examples file.xpl and filebin.xpl from Henry S. Thompson

[+] [closed] Re: Examples for p:data are still using p:file from Norman Walsh

004.[+] Children of p:choose - why are xpath-context and variable ordered? from Henry S. Thompson on 15-Aug-2008

[+] RE: Children of p:choose - why are xpath-context and variable ordered? from Toman_Vojtech@emc.com

[+] Re: Children of p:choose - why are xpath-context and variable ordered? from Norman Walsh

[+] [closed] Re: Children of p:choose - why are xpath-context and variable ordered? from Henry S. Thompson

003.[+] rdf accommodation from Paul Tyson on 14-Aug-2008

[+] Re: rdf accommodation from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 18 Aug 2008 22:21:12 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m23al1lp7r.fsf@nwalsh.com>

/ Paul Tyson <phtyson@sbcglobal.net> was heard to say:
| Did the WG consider including some standard step definitions for RDF
| processing?  At minimum, an optional p:sparql analog to p:xslt seems
| reasonable.  Beyond that, some convenience definitions for simple
| graph modifications would enable RDF processing comparable to what is
| now provided for XML processing.

It's difficult to judge how wide the XProc WG should cast its net in
search of optional steps. As chair, especially now, my instinct is to
do everything reasonable to limit rather than extend our current
scope.

That said, a p:sparql step doesn't seem like a bad idea, but I fear
the same could be said for two, three, ten, perhaps a hundred other
steps.

| RDF processing steps can easily be defined and implemented by 3rd
| parties, using the existing framework.  But I expect there will be a
| proliferation of variant definitions that will impede portability of
| xproc scripts for RDF processing.

I hope that exproc.org (like exslt.org) will help the community adopt
standard signatures for popular steps. Not that I've done much with it
yet.

| Perhaps the step definitions for RDF processing could be specified in
| a profile or module so that existing implementations will not be
| affected, and future implementations can choose whether to support
| them.

I think that it would be great if a community of RDF users and
implementors wanted to define a collection of RDF-related steps.
Speaking strictly for myself, I'd even be willing to propose that such
a document be published as a WG Note.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Through space the universe grasps me
http://nwalsh.com/            | and swallows me up like a speck;
                              | through thought I grasp it.-- Pascal

Received on Tuesday, 19 August 2008 02:21:54 GMT

[+] Re: rdf accommodation from Paul Tyson

[+] Re: rdf accommodation from Norman Walsh

[+] Re: rdf accommodation from Paul Tyson

[+] Re: rdf accommodation from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 26 Aug 2008 07:44:47 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2myj0q9u8.fsf@nwalsh.com>

Paul Tyson <phtyson@sbcglobal.net> writes:

> I must retract my suggestion for handling RDF in xproc. I had imagined
> xproc to be something it isn't.  What I had hoped for was something
> like "an XML vocabulary and syntax for defining pipelines to process
> various serializations of W3C-standard data instances".  But I see on
> closer reading that it is nothing like that.

Well, I suppose it's a matter of perspective, but I think it's exactly
like that except that it processes the XML serialization of various
formats.

> Maybe it's not too far off, though.  Consider how a few simple changes
> would greatly expand the scope and power of xproc, without affecting
> its core XML processing capabilities:
>
> 1. Eliminate the requirement that says port-to-port data flow must be
> XML.  Instead, use some phrase that means "serialized data instance",
> or simply "data stream", a serialization of some data format specified
> by W3C.  (Actually, why shouldn't this just say "behave as if ...",
> instead of specifying the data stream?)

How would this expand its scope or power? Do you have in mind a
specific example of a use case that would be possible if the XML
constraint was relaxed but is not possible without relaxing it?

> 2. Provide a type-checking mechanism on input ports to report a
> dynamic error when a port receives data it can't handle (instead of
> just XD0001 non-xml).  This could default to XML.

Allowing non-XML data would certainly introduce new interoperability
issues.

> With these changes, xproc would be equipped to handle semantic
> processing of rdf, owl, or any other type of w3c data that has a
> non-xml syntax.

RDF and OWL both *have* XML syntaxes, so there's nothing about XProc
that's unable to handle them now. Surely the decision to send N3 or
RDF/XML through a particular pipe is an implementation detail that the
user doesn't care about.

> While the current draft addresses a large body of current mainstream
> XML processing, it fails to meet the growing need for combined
> syntactic and semantic processing.  I don't know of any other WG that
> aims to meet this need.  XProc has laid the groundwork for everything
> required in a pipeline language, so any separate effort for semantic
> processing would be largely redundant.

I don't think the WG will consider expanding the scope in V1, though I
suppose it's a possibility in some future version. However, it will
have to be motivated by use cases that are prevented by the current
constraints.

I remain convinced that some RDF steps would be (will be!) valuable in
XProc, but aside from p:sparql, haven't heard any specific
suggestions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Next to knowing when to seize an
http://nwalsh.com/            | opportunity, the most important thing
                              | in life is to know when to forego an
                              | advantage.--Benjamin Disraeli

Received on Tuesday, 26 August 2008 11:45:43 GMT

[+] Re: rdf accommodation from Paul Tyson

From: Paul Tyson <phtyson@sbcglobal.net>
Date: Tue, 26 Aug 2008 19:25:09 -0500
Message-ID: <48B49EE5.5080706@sbcglobal.net>
To: public-xml-processing-model-comments@w3.org

Norman Walsh wrote:
> Paul Tyson <phtyson@sbcglobal.net> writes:
> 
> 
>>
>>1. Eliminate the requirement that says port-to-port data flow must be
>>XML.  Instead, use some phrase that means "serialized data instance",
>>or simply "data stream", a serialization of some data format specified
>>by W3C.  (Actually, why shouldn't this just say "behave as if ...",
>>instead of specifying the data stream?)
> 
> 
> How would this expand its scope or power? Do you have in mind a
> specific example of a use case that would be possible if the XML
> constraint was relaxed but is not possible without relaxing it?
>

No, I don't.  I can only say that more options are better than fewer 
when there is little cost to the more.  And, although never impossible, 
it is usually burdensome to serialize and deserialize logic statements 
to and from XML.  This just raises the barrier to semantic processing 
with xproc.

> 
>>2. Provide a type-checking mechanism on input ports to report a
>>dynamic error when a port receives data it can't handle (instead of
>>just XD0001 non-xml).  This could default to XML.
> 
> 
> Allowing non-XML data would certainly introduce new interoperability
> issues.
> 

Very few.  Associate an "allowed-types" setting on each input port 
(default to "text/xml").   Associate a "types" setting to each output 
port.  Then you could statically check both for pipeline sanity and 
implementation capability.

Yes, this allows people to write xproc scripts that use flow types that 
aren't supported in all implementations.  But if you limit the 
capabilities of the language, implementors will add non-standard 
features that render the xproc scripts non-portable anyway.  Better to 
provide a standard optional-feature list that implementors can implement 
and xproc writers can write for.  Maybe a "type-implemented" boolean 
function.

> 
>>With these changes, xproc would be equipped to handle semantic
>>processing of rdf, owl, or any other type of w3c data that has a
>>non-xml syntax.
> 
> 
> RDF and OWL both *have* XML syntaxes, so there's nothing about XProc
> that's unable to handle them now. Surely the decision to send N3 or
> RDF/XML through a particular pipe is an implementation detail that the
> user doesn't care about.
> 

Nor should the specification care about! (Other than for type checking.)

> 
>>While the current draft addresses a large body of current mainstream
>>XML processing, it fails to meet the growing need for combined
>>syntactic and semantic processing.  I don't know of any other WG that
>>aims to meet this need.  XProc has laid the groundwork for everything
>>required in a pipeline language, so any separate effort for semantic
>>processing would be largely redundant.
> 
> 
> I don't think the WG will consider expanding the scope in V1, though I
> suppose it's a possibility in some future version. However, it will
> have to be motivated by use cases that are prevented by the current
> constraints.

My personal experience when learning a pipeline framework was that I 
quickly dreamed up new applications that were beyond the capabilities of 
the framework, and were probably not among the use cases considered by 
the framework designers.  But I wouldn't have thought of these 
applications unless I first learned the framework.  For an enabling 
technology like this it is impossible to enumerate, _a priori_, all the 
problems it will solve.

I think you have a genii in a bottle here, and I'd like to see him come 
out in V1 rather than later.

> 
> I remain convinced that some RDF steps would be (will be!) valuable in
> XProc, but aside from p:sparql, haven't heard any specific
> suggestions.

See my "rdf processing steps" submission to this list.

Thanks for your consideration,
--Paul

Received on Wednesday, 27 August 2008 00:23:25 GMT

[+] Re: rdf accommodation from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 26 Aug 2008 22:15:44 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2hc97gq3z.fsf@nwalsh.com>

Paul Tyson <phtyson@sbcglobal.net> writes:

> Norman Walsh wrote:
>> Paul Tyson <phtyson@sbcglobal.net> writes:
>>
>>
>>>
>>>1. Eliminate the requirement that says port-to-port data flow must be
>>>XML.  Instead, use some phrase that means "serialized data instance",
>>>or simply "data stream", a serialization of some data format specified
>>>by W3C.  (Actually, why shouldn't this just say "behave as if ...",
>>>instead of specifying the data stream?)
>>
>>
>> How would this expand its scope or power? Do you have in mind a
>> specific example of a use case that would be possible if the XML
>> constraint was relaxed but is not possible without relaxing it?
>>
>
> No, I don't.  I can only say that more options are better than fewer
> when there is little cost to the more.  And, although never
> impossible, it is usually burdensome to serialize and deserialize
> logic statements to and from XML.  This just raises the barrier to
> semantic processing with xproc.

Well, perhaps, but in this case, I think the cost of having more
options (the interoperability problems, definition of the mechanisms
by which options are recognized, etc.) outweigh the benefits. But
we may simple disagree on that point.

>>>2. Provide a type-checking mechanism on input ports to report a
>>>dynamic error when a port receives data it can't handle (instead of
>>>just XD0001 non-xml).  This could default to XML.
>>
>>
>> Allowing non-XML data would certainly introduce new interoperability
>> issues.
>>
>
> Very few.  Associate an "allowed-types" setting on each input port
> (default to "text/xml").   Associate a "types" setting to each output
> port.  Then you could statically check both for pipeline sanity and
> implementation capability.

That's the bare minimum necessary to achieve interoperability, but it
doesn't guarantee it unless all implementations are required to
support all allowed-types (even assuming a list of "all" could be
constructed).

> Yes, this allows people to write xproc scripts that use flow types
> that aren't supported in all implementations.  But if you limit the
> capabilities of the language, implementors will add non-standard
> features that render the xproc scripts non-portable anyway.  Better to
> provide a standard optional-feature list that implementors can
> implement and xproc writers can write for.  Maybe a "type-implemented"
> boolean function.

Better I think to encourage a small set of standard mechanisms.
Again, we may simply disagree.

>> I don't think the WG will consider expanding the scope in V1, though I
>> suppose it's a possibility in some future version. However, it will
>> have to be motivated by use cases that are prevented by the current
>> constraints.
>
> My personal experience when learning a pipeline framework was that I
> quickly dreamed up new applications that were beyond the capabilities
> of the framework, and were probably not among the use cases considered
> by the framework designers.  But I wouldn't have thought of these
> applications unless I first learned the framework.  For an enabling
> technology like this it is impossible to enumerate, _a priori_, all
> the problems it will solve.
>
> I think you have a genii in a bottle here, and I'd like to see him
> come out in V1 rather than later.

Indeed. But on the other hand, I want to make sure that the lamp is
small enough and light enough that everone picks it up and tries his
or her hand at rubbing it.

Undoubtably, users and implementors will dream up uses beyond what
we've considered. No amount of engineering can prevent that (nor would
I want to!)

If XProc is successful, we'll be able to revisit these issues with
real world examples to guide us towards where additional
standardization would be useful.

>> I remain convinced that some RDF steps would be (will be!) valuable in
>> XProc, but aside from p:sparql, haven't heard any specific
>> suggestions.
>
> See my "rdf processing steps" submission to this list.

Yes, thank you. I sent my previous reply before seeing that message.
I have, as you suggested, sent mail to the chairs of the SWD WG asking
for their input.

> Thanks for your consideration,

And thank you for your thoughtful comments.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | There is no such thing as an absolute
http://nwalsh.com/            | certainty, but there is assurance
                              | sufficient for the purposes of human
                              | life.--John Stuart Mill

Received on Wednesday, 27 August 2008 02:16:26 GMT

[+] rdf processing steps from Paul Tyson

[+] Re: rdf processing steps from Dave Pawson

[+] [closed] Re: rdf accommodation from Norman Walsh

[+] Re: [closed] Re: rdf accommodation from Paul Tyson

002.[+] more comments on latest xproc II from James Fuller on 15-Apr-2008

From: James Fuller <james.fuller.2007@gmail.com>
Date: Wed, 16 Apr 2008 00:27:43 +0200
Message-ID: <a0ad8ffe0804151527k70ffd69ct4bf25abafa683f77@mail.gmail.com>
To: public-xml-processing-model-comments@w3.org


------------------------------------

in section 3 Syntax Overview

'Six kinds of things are named in XProc:'

propose refining to

'There are six kinds of entities defined in XProc'

named implies that they have a @name attribute, where as 'things' is a
bit of a wholly term

------------------------------------

minor nit with p:variable

in section 2.1 Steps subpipeline is defined to take a top level p:variable

subpipeline = p:variable*,
(p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+

furthermore p:choose and p:try can also have a top level p:variable
defined ... should we harmonize this usage of p:variable
and allow outside of nested subpipeline on p:for-each, p:viewport, and
p:group elements as well ?

------------------------------------

should we add some concept of http timeout on c:request ? perhaps as
an optional option

same thing goes for proxy

also, I did not see any discussion, but I may have missed it  .... did
the WG consider any need for an HTTP_REFERER type element in
c:response ? I would propose adding it to the c:http-response element
as an attribute.

------------------------------------

in section 7.1.15 p:namespace-rename

this step has always seemed to me slightly incorrect, e.g. the
operation that is occuring is more appropriately called
namespace-mapping ... I prefer how XSLT 2.0 approaches this using
namespace-alias function ... below is a rough translation of what this
would look like in XProc

<p:namespace-alias xmlns:old="http://someold.com/namespace"
xmlns:new="somenew.com/namespace">
	<p:option name="literalNS" value="old"/>
	<p:option name="targetNS" value="new"/>
</p:namespace-alias>

I think its pretty clear and would propose we add to steps (and remove
namespace-rename)

------------------------------------

cheers, Jim Fuller

Received on Tuesday, 15 April 2008 22:28:18 GMT

[+] Re: more comments on latest xproc II from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 21 Aug 2008 07:55:31 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2tzdewpjg.fsf@nwalsh.com>

/ James Fuller <james.fuller.2007@gmail.com> was heard to say:
| ------------------------------------
|
| in section 3 Syntax Overview
|
| 'Six kinds of things are named in XProc:'
|
| propose refining to
|
| 'There are six kinds of entities defined in XProc'
|
| named implies that they have a @name attribute, where as 'things' is a
| bit of a wholly term

Yeah, but entities has baggage too in the XML world.. Anyone got
another suggestion?

| minor nit with p:variable
|
| in section 2.1 Steps subpipeline is defined to take a top level p:variable
|
| subpipeline = p:variable*,
| (p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+
|
| furthermore p:choose and p:try can also have a top level p:variable
| defined ... should we harmonize this usage of p:variable
| and allow outside of nested subpipeline on p:for-each, p:viewport, and
| p:group elements as well ?

To what end? The only reason p:variable is called out explicitly in
p:choose and p:try is because those steps don't directly contain
subpipelines.

| should we add some concept of http timeout on c:request ? perhaps as
| an optional option

Perhaps.

| same thing goes for proxy

You mean a way of specifiying a proxy? I think that belongs at the
application or even OS level, not in the pipeline.

| also, I did not see any discussion, but I may have missed it  .... did
| the WG consider any need for an HTTP_REFERER type element in
| c:response ? I would propose adding it to the c:http-response element
| as an attribute.

It's a header, isn't it? So you can get it back if you ask for the
details and you can pass it in if you wish. Or am I totally confused?

| in section 7.1.15 p:namespace-rename
|
| this step has always seemed to me slightly incorrect, e.g. the
| operation that is occuring is more appropriately called
| namespace-mapping ... I prefer how XSLT 2.0 approaches this using
| namespace-alias function ... below is a rough translation of what this
| would look like in XProc
|
| <p:namespace-alias xmlns:old="http://someold.com/namespace"
| xmlns:new="somenew.com/namespace">
| 	<p:option name="literalNS" value="old"/>
| 	<p:option name="targetNS" value="new"/>
| </p:namespace-alias>
|
| I think its pretty clear and would propose we add to steps (and remove
| namespace-rename)

That seems like a pretty significant design change for what my
experience suggests is a very, very small edge case. In my decade or
so of XSLT use, I think I've used namespace aliasing just about twice.
I think we have to provide a step to do it, but I don't think we have
to work hard to make it easy.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Most human beings have an almost
http://nwalsh.com/            | infinite capacity for taking things for
                              | granted.--Aldous Huxley

Received on Thursday, 21 August 2008 11:56:36 GMT

[+] Re: more comments on latest xproc II from James Fuller

From: James Fuller <james.fuller.2007@gmail.com>
Date: Thu, 21 Aug 2008 14:25:08 +0200
Message-ID: <a0ad8ffe0808210525t25fd7f44k79ea28acea6e21d8@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org


On Thu, Aug 21, 2008 at 1:55 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
> | ------------------------------------
> |
> | in section 3 Syntax Overview
> |
> | 'Six kinds of things are named in XProc:'
> |
> | propose refining to
> |
> | 'There are six kinds of entities defined in XProc'
> |
> | named implies that they have a @name attribute, where as 'things' is a
> | bit of a wholly term
>
> Yeah, but entities has baggage too in the XML world.. Anyone got
> another suggestion?

constituents, components, items ...

> | minor nit with p:variable
> |
> | in section 2.1 Steps subpipeline is defined to take a top level p:variable
> |
> | subpipeline = p:variable*,
> | (p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+
> |
> | furthermore p:choose and p:try can also have a top level p:variable
> | defined ... should we harmonize this usage of p:variable
> | and allow outside of nested subpipeline on p:for-each, p:viewport, and
> | p:group elements as well ?
>
> To what end? The only reason p:variable is called out explicitly in
> p:choose and p:try is because those steps don't directly contain
> subpipelines.

ok I understand this now (after implementing it)

> | should we add some concept of http timeout on c:request ? perhaps as
> | an optional option
>
> Perhaps.

thx for considering

> | same thing goes for proxy
>
> You mean a way of specifiying a proxy? I think that belongs at the
> application or even OS level, not in the pipeline.

it does, but there maybe scenarios where you would like to configure
everything from within xproc ... and configure proxy explicitly

> | also, I did not see any discussion, but I may have missed it  .... did
> | the WG consider any need for an HTTP_REFERER type element in
> | c:response ? I would propose adding it to the c:http-response element
> | as an attribute.
>
> It's a header, isn't it? So you can get it back if you ask for the
> details and you can pass it in if you wish. Or am I totally confused?

get back to you on this one, need to remind myself just what I was highlighting


> | in section 7.1.15 p:namespace-rename
> |
> | this step has always seemed to me slightly incorrect, e.g. the
> | operation that is occuring is more appropriately called
> | namespace-mapping ... I prefer how XSLT 2.0 approaches this using
> | namespace-alias function ... below is a rough translation of what this
> | would look like in XProc
> |
> | <p:namespace-alias xmlns:old="http://someold.com/namespace"
> | xmlns:new="somenew.com/namespace">
> |       <p:option name="literalNS" value="old"/>
> |       <p:option name="targetNS" value="new"/>
> | </p:namespace-alias>
> |
> | I think its pretty clear and would propose we add to steps (and remove
> | namespace-rename)
>
> That seems like a pretty significant design change for what my
> experience suggests is a very, very small edge case. In my decade or
> so of XSLT use, I think I've used namespace aliasing just about twice.
> I think we have to provide a step to do it, but I don't think we have
> to work hard to make it easy.

agreed.

ta, J
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | Most human beings have an almost
> http://nwalsh.com/            | infinite capacity for taking things for
>                              | granted.--Aldous Huxley
>

Received on Thursday, 21 August 2008 12:25:47 GMT

001.[+] a few comments on latest draft from James Fuller on 15-Apr-2008

From: James Fuller <james.fuller.2007@gmail.com>
Date: Tue, 15 Apr 2008 21:09:51 +0200
Message-ID: <a0ad8ffe0804151209i2918166bu732b0fcb66a69adc@mail.gmail.com>
To: public-xml-processing-model-comments@w3.org


------------------------

Example 3. A validate and transform pipeline

propose highlighting the use of an Optional step (p:validate-with-xml-schema)

------------------------

should we explicitly define primary outputs in Standard and Optional steps ?

------------------------

in section 1 Introduction

'The pipeline document determines how the steps are connected together
inside the pipeline. How inputs are connected to XML documents outside
the pipeline is implementation-defined. How pipeline outputs are
connected to XML documents outside the pipeline is
implementation-defined.'

do we want to delineate between the 'outside world' e.g. the top level
pipeline versus a pipeline that is executing in the context of a
nested pipeline ?

------------------------

in section 2 Pipeline Concepts

'A pipeline must behave as if it evaluated each step each time it occurs.'

is it more valid to say  memoisation is not allowed ... or is this too
constraining ?

what is the primary scenario where this applies ?

------------------------

in section 1 it says

'There are two kinds of steps: atomic steps and compound steps.'

in section 2.1 Steps

'There are three kinds of steps: atomic, compound, and multi-container.'

I propose syncing these

------------------------

in section 2.1.1 Step names

I am a unsure about the need to specifically prescribe the manufactured format
I propose to keep existing text but frame it as an 'example'.

------------------------

I must have lost the thread on this discussion but what happens when

<p:declare-step
  xpath-version? = string>

and a pipelines xpath-version

have different values ... is this a static error ? just need a pointer here

------------------------

probably need to expand the definition of pfx:user-pipeline ... somewhere

also, shouldn't p:standard-step be pfx:atomic-step ?

------------------------

more comments coming ;)

cheers, Jim Fuller

Received on Tuesday, 15 April 2008 19:10:25 GMT

[+] Re: a few comments on latest draft from Norman Walsh

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 21 Aug 2008 07:49:55 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2y72qwpss.fsf@nwalsh.com>

/ James Fuller <james.fuller.2007@gmail.com> was heard to say:
| Example 3. A validate and transform pipeline
|
| propose highlighting the use of an Optional step (p:validate-with-xml-schema)

I suppose we could, but does it add value?

| should we explicitly define primary outputs in Standard and Optional steps ?

I don't understand the question.

| in section 1 Introduction
|
| 'The pipeline document determines how the steps are connected together
| inside the pipeline. How inputs are connected to XML documents outside
| the pipeline is implementation-defined. How pipeline outputs are
| connected to XML documents outside the pipeline is
| implementation-defined.'
|
| do we want to delineate between the 'outside world' e.g. the top level
| pipeline versus a pipeline that is executing in the context of a
| nested pipeline ?

Isn't that what that paragraph does?

| in section 2 Pipeline Concepts
|
| 'A pipeline must behave as if it evaluated each step each time it occurs.'
|
| is it more valid to say  memoisation is not allowed ... or is this too
| constraining ?

For the benefit of readers unfamiliar with the technical term, I'm not
inclined to make this change.

| what is the primary scenario where this applies ?

It's just a way of saying that implementations can't cache results and
only evaluate a step once.

| in section 1 it says
|
| 'There are two kinds of steps: atomic steps and compound steps.'
|
| in section 2.1 Steps
|
| 'There are three kinds of steps: atomic, compound, and multi-container.'
|
| I propose syncing these

Yes. Done.

| in section 2.1.1 Step names
|
| I am a unsure about the need to specifically prescribe the manufactured format
| I propose to keep existing text but frame it as an 'example'.

I think we decided that we'd like to define it, though I suppose
that's not strictly necessary.

| I must have lost the thread on this discussion but what happens when
|
| <p:declare-step
|   xpath-version? = string>
|
| and a pipelines xpath-version
|
| have different values ... is this a static error ? just need a pointer here

That text has been clarified, I think. If you don't find it clear now,
please let us know.

| probably need to expand the definition of pfx:user-pipeline ... somewhere
|
| also, shouldn't p:standard-step be pfx:atomic-step ?

I think we worked on this too. Let us know if you still have questions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | To what excesses will men not go for
http://nwalsh.com/            | the sake of a religion in which they
                              | believe so little and which they
                              | practice so imperfectly!--La Bruyère

Received on Thursday, 21 August 2008 11:51:01 GMT

[+] Re: a few comments on latest draft from James Fuller

From: James Fuller <james.fuller.2007@gmail.com>
Date: Thu, 21 Aug 2008 14:19:16 +0200
Message-ID: <a0ad8ffe0808210519h5cd0afa8vf29e7905325e39d6@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org


On Thu, Aug 21, 2008 at 1:49 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
> | Example 3. A validate and transform pipeline
> |
> | propose highlighting the use of an Optional step (p:validate-with-xml-schema)
>
> I suppose we could, but does it add value?

only a little to newbies

> | should we explicitly define primary outputs in Standard and Optional steps ?
>
> I don't understand the question.

I dont either anymore .. I think this was already addressed as the
text read fine now.

> | in section 1 Introduction
> |
> | 'The pipeline document determines how the steps are connected together
> | inside the pipeline. How inputs are connected to XML documents outside
> | the pipeline is implementation-defined. How pipeline outputs are
> | connected to XML documents outside the pipeline is
> | implementation-defined.'
> |
> | do we want to delineate between the 'outside world' e.g. the top level
> | pipeline versus a pipeline that is executing in the context of a
> | nested pipeline ?
>
> Isn't that what that paragraph does?

yes.


> | in section 2 Pipeline Concepts
> |
> | 'A pipeline must behave as if it evaluated each step each time it occurs.'
> |
> | is it more valid to say  memoisation is not allowed ... or is this too
> | constraining ?
>
> For the benefit of readers unfamiliar with the technical term, I'm not
> inclined to make this change.

ok

> | in section 1 it says
> | in section 2.1.1 Step names
> |
> | I am a unsure about the need to specifically prescribe the manufactured format
> | I propose to keep existing text but frame it as an 'example'.
>
> I think we decided that we'd like to define it, though I suppose
> that's not strictly necessary.

ok, loosening the definition makes it easier for impl.

> | I must have lost the thread on this discussion but what happens when
> |
> | <p:declare-step
> |   xpath-version? = string>
> |
> | and a pipelines xpath-version
> |
> | have different values ... is this a static error ? just need a pointer here
>
> That text has been clarified, I think. If you don't find it clear now,
> please let us know.

yes its fine now.

>
> | probably need to expand the definition of pfx:user-pipeline ... somewhere
> |
> | also, shouldn't p:standard-step be pfx:atomic-step ?
>
> I think we worked on this too. Let us know if you still have questions.

yes fine now.

J

Received on Thursday, 21 August 2008 12:19:54 GMT

XProc Last Call Comments

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