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

XProc Last Call Comments

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