XProc CR Disposition of Comments

Florent Georges <fgeorges@fgeorges.org> writes:
[...]
>   It seems too restrictive to me, as other authentication methods
> than RFC 2617 can be used.  The text later says:
>
>     The interpretation of auth-method values on c:request other
>     than “Basic” or “Digest” is implementation-defined.
>
> but it is not clear IMHO whether the implementation-defined
> behaviour must be kept within the scope of RFC 2617.  I guess
> something like the following would be more clear:
>
>     If the username attribute is specified, the username,
>     password, auth-method, and send-authorization attributes are
>     used to handle authentication, depending on the chosen
>     authentication method.
>
>     [...]
>
>     If the authentication method is either "basic" or "digest",
>     authentication is handled as per [RFC 2617].

At the 17 Dec 2009 telcon, the WG agreed substantially with your
request and plans to make the changes you suggest.

>   Furthermore, it is not said that the value of auth-method is
> case-insensitive (which I guess is the intention).

As far as I can tell, the values specified by RFC2617 *are*
case-sensitive.

>   Last but not least, shouldn't we reserve the method "token" for
> the standardization-in-progress "HTTP Authentication: Token
> Access Authentication", the IETF standardization of the popular
> (and couting) OAuth method:
>
> http://xml.coverpages.org/draft-hammer-http-token-auth-00.txt

Not before that spec is finished.

Please let us know if you're unsatisfied by these resolutions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Not to be absolutely certain is, I
http://nwalsh.com/            | think, one of the essential things in
                              | rationality.--Bertrand Russell

"Henry S. Thompson" <ht@inf.ed.ac.uk> writes:
> While we're getting our wishlist out (see Norm's previous posting) for
> obscure facilities which we need for pipelines we're writing, I've
> finally been converted to the restricting-values-to-strings-is-crazy
> position.

Welcome. Don't worry, we're friendly.

> But here's why we're _not_ going to do this in V1:  it would take a
> substantial amount of work to decide how to get things _back_ from
> such values.

Really? I'd have thought string($expr) was the obvious answer.

>  Would we allow, e.g.,
>
>  <p:declare-step type="my:demo">
>   <p:output name="result" sequence="true" primary="true"/>
>   <p:option name="attrSet"/>
>
>   <p:identity select="$attrSet"/>
>   <p:for-each>
>    <p:load>
>     <p:with-option name="href" select="."/>
>    </p:load>
>   </p:for-each>
>  </p:pipeline>
>
> To be useful, such a pipeline would need to be allowed.  But that's
> too big a change for this late in the game. . .

I was so convinced that it was both necessary and easy to do that I
implemented sequences of nodes as values in XML Calabash. If you use
the "-X general-values" option, XML Calabash is a non-conforming
processor that (probably) does what you want.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In science, "fact" can only mean
http://nwalsh.com/            | "confirmed to such a degree that it
                              | would be perverse to withhold
                              | provisional assent." I suppose that
                              | apples might start to rise tomorrow,
                              | but the possibility does not merit
                              | equal time in physics
                              | classrooms.--Stephen J. Gould

"Henry S. Thompson" <ht@inf.ed.ac.uk> writes:
> While we're getting our wishlist out (see Norm's previous posting) for
> obscure facilities which we need for pipelines we're writing, I've
> finally been converted to the restricting-values-to-strings-is-crazy
> position.

Per the minutes of the 3 Dec 2009 telcon: no new features in V1.0.
Please let us know if you are not satisified by this resolution.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Blessed is the man who, having nothing
http://nwalsh.com/            | to say, abstains from giving wordy
                              | evidence of the fact.--George Eliot

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

Vasil Rangelov writes:

> "It is a static error (err:XS0029) to specify a connection for a p:output
> inside a p:declare-step for an atomic step."
>
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
>                 name="xinclude-and-validate"
>                 version="1.0">
>   <p:input port="source" primary="true"/>
>   <p:input port="schemas" sequence="true"/>
>   <p:output port="result">
>     <p:pipe step="validated" port="result"/>
>   </p:output>
>

Easy to misunderstand, I guess, but note the word 'atomic'.  Your
example is not an atomic step == an extension step with
implementation-built-in, as opposed to specified using XProc.

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)

iD8DBQFK9KnXkjnJixAXWBoRAnfPAJ0ep2Sct6GwlBtReY7Hjtl0AWd+nwCdFPdy
8siuZWv32ta1kaBKPY9smnw=
=NiVN
-----END PGP SIGNATURE-----

Vasil Rangelov <boen.robot@gmail.com> writes:
> Latest editor's draft, 3 November 2009
>
> 1) 5.4 p:output says
>
> "It is a static error (err:XS0029) to specify a connection for a p:output
> inside a p:declare-step for an atomic step."
>
> How is a step supposed to produce an output then?

It doesn't say you can't declare an output, it says you can't declare
a connection for it.

This is OK:

<p:declare-step type="ex:mystep">
  <p:input name="source"/>
  <p:output name="result1"/>
  <p:output name="result2"/>
</p:declare-step>

This isn't:

<p:declare-step type="ex:mystep">
  <p:input name="source"/>
  <p:output name="result1">
    <p:inline>
      <doc/>
    </p:inline>
  </p:output>
  <p:output name="result2"/>
</p:declare-step>

> Especially one where the
> result comes from a non-primary port of a step, or where it comes from the
> primary output port of a step other than the latest one. Consider the very
> first example:
>
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
>                 name="xinclude-and-validate"
>                 version="1.0">
>   <p:input port="source" primary="true"/>
>   <p:input port="schemas" sequence="true"/>
>   <p:output port="result">
>     <p:pipe step="validated" port="result"/>
>   </p:output>
>
>   <p:xinclude name="included">
>     <p:input port="source">
>       <p:pipe step="xinclude-and-validate" port="source"/>
>     </p:input>
>   </p:xinclude>
>
>   <p:validate-with-xml-schema name="validated">
>     <p:input port="source">
>       <p:pipe step="included" port="result"/>
>     </p:input>
>     <p:input port="schema">
>       <p:pipe step="xinclude-and-validate" port="schemas"/>
>     </p:input>
>   </p:validate-with-xml-schema>
> </p:declare-step>
>
> Doesn't the above sentence mean this creates a static error? Or am I wrong
> in assuming that "connection" is equivalent to "binding"?

Connection is equivalent to binding, but that's not an atomic step.

> 2) What happens if a connection is provided upon a call to an atomic step?
> Is this a static error, and if not, does the connection get used if the
> returned output is empty (and/or simply not populated by the step), or does
> it completely abolish whatever the step may have produced on that port?

A connection is only allowed in a p:output on a compound step.

> In other words, what happens if I have, say:
>
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0"
> name="pipeline">
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="stylesheet.xsl"/>
>     </p:input>
>     <p:with-option name="version" value="2.0"/>
>     <p:output port="secondary">
>       <p:pipe step="pipeline" port="source"/>
>     </p:output>
>   </p:xslt>
> </p:pipeline>

That's an error.

Section 3.11 defines err:XS0044 for "any element in the XProc
namespace ... [that] has element children other than those specified
by this specification".

Section 5.4 defines p:output as empty then further qualifies that
definition with the statement that on "compound steps, the declaration
may be accompanied by a connection for the output."

So I assert that err:XS0044 applies in the case of your example above.

> Personally, I think this should either be explicitly stated as a static
> error

Fair enough. I don't have any problem adding an explicit static error
for this case.

> OR be used as a *default* connection in case the step produces an
> empty sequence on that port.

No. Atomic steps produce what they produce. It would be wrong (IMHO)
to allow the declaration to override what the step produces.

> In the case of the above example, it could mean
> that the source document will be provided on the secondary port if the
> stylesheet didn't produced a second document, but if the stylesheet did
> produced one or more secondary documents, they'll be seen there.

*Way* to complicated.

> 3) Is p:empty the default connection for the non-primary outputs of steps?

For atomic steps, there is no default, the step produces what it produces.
It's a black box.

For compound steps, there is no default, but if you leave them
unconnected then they will produce an empty sequence.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | What is familiar is what we are used
http://nwalsh.com/            | to; and what we are used to is most
                              | difficult to 'Know'--that is, to see as
                              | a problem; that is, to see as strange,
                              | as distant, as 'outside us'.-- Nietzsche

"Vasil Rangelov" <boen.robot@gmail.com> writes:
> Hmmm... so... let me get this straight... when p:declare-step has a sub
> pipeline, it declares a pipeline, and it is said that a user really "calls a
> pipeline". When p:declare-step doesn't have a sub pipeline, it declares an
> "atomic extension step" and the user "calls an atomic extension step".

I think it's less complicated than that. In this context, whether
something is an extension step or not is irrelevant, so let's set that
to one side for a moment.

A p:declare-step declares a step. If that declaration includes a body,
then the body is the definition of the step. If the declaration is
empty, then the definition of the step is known to the processor
through some other means.

In either case, the declaration declares a type of step.

If a user uses places an element whose QName is the same as the name
of that type of step in a subpipeline, then the processing defined by
that step is performed.

So:

  <p:declare-step type="ex:my-first-step">
    <p:input port="source"/>
    <p:output port="result"/>
  </p:declare-step>

declares a step (that happens to be atomic) of the type
"ex:my-first-step".

  <p:declare-step type="ex:my-second-step">
    <p:input port="source"/>
    <p:output port="result"/>
    <p:identity/>
  </p:declare-step>

declares a step (that happens not to be atomic) of type type
"ex:my-second-step".

I can use these steps in my pipelines without concern for whether they
are atomic or not, their *use* is *always* "atomic" in the sense that
it never contains a body:

  <p:pipeline>
    <ex:my-first-step/>
    <ex:my-second-step/>
  </p:pipeline>

> Rules
> that apply to atomic (extension or built in) steps don't apply to pipelines,
> and vice-versa...

The only difference with respect to connections is that in the
declaration of a step that is not atomic, the author can provide
bindings for the inputs and outputs.

In the case of inputs, these connections are used if no explicit or
implicit binding is provided. In the case of outputs, these
connections define what the output of the step will be when it's
called.

Consider:

  <p:declare-step type="ex:my-third-step">
    <p:input port="source" primary="true">
      <p:inline><doc1/></p:inline>
    </p:input>
    <p:input port="secondary" primary="false">
      <p:inline><doc2/></p:inline>
    </p:input>
    <p:output port="result" primary="true"/>
    <p:output port="result2" primary="false">
      <p:inline><doc3/></p:inline>
    </p:input>
    <p:identity/>
  </p:declare-step.

And here's where it's used:

   ...
   <p:identity/>
   <ex:my-third-step/>

When ex:my-third-step runs, its primary input port "source" will be bound
to the default readable port ("result" from the identity step), so the
default input "<doc1/>" will not be used.

There isn't a binding for the "secondary" input, so it will be bound to
"<doc2/>".

The "result" output has no binding, so it will be bound to the default
readable port of the last step, another identity step in this case.

The "result2" output will be bound to "<doc3/>".

If you did this:

  <p:declare-step type="ex:my-third-step">
    <p:input port="source" primary="true">
      <p:inline><doc1/></p:inline>
    </p:input>
    <p:input port="secondary" primary="false">
      <p:inline><doc2/></p:inline>
    </p:input>
    <p:output port="result" primary="true">
      <p:inline><doc4/></p:inline>
    </p:output>
    <p:output port="result2" primary="false">
      <p:inline><doc3/></p:inline>
    </p:input>
    <p:identity/>
  </p:declare-step>

You'd get an error because the primary output of the last step is
unconnected. You coudld do this:

  <p:declare-step type="ex:my-third-step">
    <p:input port="source" primary="true">
      <p:inline><doc1/></p:inline>
    </p:input>
    <p:input port="secondary" primary="false">
      <p:inline><doc2/></p:inline>
    </p:input>
    <p:output port="result" primary="true">
      <p:inline><doc4/></p:inline>
    </p:output>
    <p:output port="result2" primary="false">
      <p:inline><doc3/></p:inline>
    </p:input>
    <p:identity/>
    <p:sink/>
  </p:declare-step>

But that's a pretty pointless pipeline.

If you're declaring a step that isn't atomic, you can't put any sort
of default bindings in the inputs or outputs because you don't have
any visibility into what the step does.

> but aren't there some rules that apply to both atomic
> steps and pipelines? If so, is there a common term to refer to them both (I
> don't remember ever seeing a phrase like "atomic steps or pipelines")? Where
> do "atomic extension steps" fit into this? Do they get the rules for
> pipelines or for "atomic steps" (standard library wise)? The spec currently
> appears to first define them separately (as if they are something truly
> "special"), and then goes on by using only the term "atomic steps".

All atomic steps are the same. The only things that are special about
atomic steps in the XProc namespace is that you can't declare any and
if you specify version > 1.0, some otherwise static errors are ignored.

In all other respects, they're just ordinary steps.

>> For atomic steps, there is no default, the step produces what it produces.
>> It's a black box.
>
> Right... for atomic steps in the standard library and p:declare-step of an
> (extension) atomic step. And for p:declare-step of a pipeline? What happens
> if there is p:output with no connection in that case? Is THAT an error, or
> do you always get some kind of a default connection (like p:empty)?

An unconnected, non-primary output port in the declaration of a
non-atomic step produces an empty sequence. I don't think of that in
terms of having a default connection to p:empty so much as simply not
having anything to read *from*.

Remember, somewhat counter-intuitively, that *inside* the declaration
of a non-atomic step, the connections inside p:outputs are *reading*
data, not writing it. Whatever they *read* gets *written to* the
output that's seen by the pipeline that invokes the declared step.

  <p:pipeline>
    ...
    <p:declare-step type="ex:foo">
      <p:output port="result">
        <p:pipe step="whatever" port="result"/>
      </p:output>
      <ex:something name="whatever"/>
    </p:declare-step>

    <ex:foo/>
    <p:identity/>
  </p:pipeline>

When "ex:foo" is invoked, the processor begins running the declared
subpipline.

The ex:something step is run. The "result" output of ex:something is
*read by* the connection declared in the ex:foo declaration and
*written to* the "result" output port that's seen by the p:identity
step that follows the call to ex:foo.

Output ports in non-atomic steps have this weird dual role that they
read stuff (usually but not necessarily) from other steps in the
subpipeline of their container and write stuff to the outputs of that
container.

>> For compound steps, there is no default, but if you leave them unconnected
> then they will produce an empty sequence.
>
> If you leave them unconnected (i.e. don't specify anything as a connection),
> isn't what they get called a "default" connection (p:empty in this case)? If
> so, aren't you contradicting yourself? Anyway, I see... p:empty it is.

The result is the same as if they were bound to p:empty, so I'm not
sure it much matters how we think about it.

I think in terms of the dual role described above. If there's no
connection, then there's nothing for the output to read from. If
there's nothing for it to read from, then it has nothing to write to
the output port.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | So, are you working on finding that bug
http://nwalsh.com/            | now, or are you leaving it until later?
                              | Yes.

Vasil Rangelov <boen.robot@gmail.com> writes:
> On second thought, in addition to that... what happens with unknown elements
> (steps or instructions*)? This is still not clear. If I recall correctly, a
> new dynamic error was going to happen. Where's the paragraph about that?

With the introduction of use-when, the WG backed off making unknown
elements from the XProc namespace a dynamic error. Given that you have
to add some sort of conditionality to make things work at all, you can
use use-when to make a 1.0 processor never see the unknown elements.

> * By that, I mean p:serialization, p:xpath-context and p:document like
> elements. Let me note again that (I for one think) these elements deserve a
> formal qualification. I'd even go as far as to suggest a function for their
> detection (especially useful with p:use-when). Say, p:element-available(),
> which would be similar to p:step-available(), only it would also detect
> "instructions" and "extension instructions". And/or there could be
> p:instruction-available(), which would only detect "instruction" elements
> (i.e. not steps). I don't feel strong for the exact term "instructions" -
> "miscellaneous" is also fine for example, but an existence of such a
> qualification would still be beneficial.

It seems to me that testing for the spec version is sufficient.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The average man, who does not know what
http://nwalsh.com/            | to do with his life, wants another one
                              | which will last forever.--Anatole France

OK. I like the new versioning story (24 October 2009... just in case that
text changes drastically in the future, I'd like to note the date) :)

Just a slight correction on it though. The text about unknown options should
also be added back. You know, the part about
"4. New options on known steps are ignored in the pipeline."

Since options can be set with p:with-option as well as attributes, the text
about unknown attributes doesn't exactly cover it.

Regards,
Vasil Rangelov

-----Original Message-----
From: public-xml-processing-model-comments-request@w3.org
[mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of
Norman Walsh
Sent: Saturday, October 24, 2009 9:46 PM
To: public-xml-processing-model-comments@w3.org
Subject: New XProc editor's WG reflects latest proposals

Hi folks,

I just published my first attempt at addressing the recent proposed changes
to the XProc spec:

  http://www.w3.org/XML/XProc/docs/langspec

I've also updated the revision markup draft, though that's getting a bit
cluttered.

Changes since the preceding editor's draft:

1. Replaced the versioning story
2. Changed default connections on p:with-option and p:with-param to p:empty
   if there's no default readable port
3. Relaxing the rules about primary parameter input ports (this item
   hasn't been discussed by the WG, so it's purely speculative on
   the part of the editor.)

Please review this draft and report any errors or omissions. 

                                        Be seeing you,
                                          norm

--
Norman Walsh <ndw@nwalsh.com> | Fast. Cheap. Well. Pick two.
http://nwalsh.com/            |