Re: XProc Editors Draft 2007-07-19: Section 2.8 Comments

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| In 2.8.1, the definition of the context node should include what
| happens if there's no default readable port, or the context is empty
| (which I think we said would mean that a document node with no child
| was used as the context).

Right.

| In 2.8.1, I think that using the in-scope namespaces on the element is
| fine, isn't it? In what way is it insufficient?

Consider:

<px:some-compound-step xmlns:foo="http://example.com/foo">
  <p:option name="qn1" value="foo:bar"/>

  <px:some-step xmlns:foo="" xmlns:bar="http://example.com/bar">
    <p:option name="qn2" value="$qn1 | bar:baz"/>

    ...

We have discussed the possibility that the in-scope namespaces for qn2
would include both foo and bar. The bar namespace because it is in
scope, the foo namespace because it was in scope when the value of
$qn1 was calculated.

But now that I write an example out, I realize that this can only
arise in compound steps and the foo namespace should be in scope for
qn2 as well as qn1. An author who arranges otherwise gets what he or
she deserves.

I'm happy to remove the note.

| In 2.8.2, the definition of the in-scope namespaces contradicts the
| definition in 5.7.3 Option and Parameter Namespace Bindings. This
| needs to be resolved one way or the other. (And I think that this *is*
| known to be insufficient.)

This is really the ugly case. Maybe this is what I was thinking of
when I wrote the note and I just put it in the wrong place.

I don't think the step *can* compute the right namespaces, I think the
processor is going to have to pass them along.

Here's my attempt to fix it:

<varlistentry>
<term>in-scope namespaces</term>
<listitem>
<para>The set of namespace bindings provided by the XProc processor.
The processor computes this set of bindings by taking a union of the
bindings on the step element itself as well as the bindings on any of
the options and parameters used in computing values for the step (see
<xref linkend="opt-param-bindings"/>).</para>

<para><impl>The results of computing the union of namespaces in the
presence of conflicting declarations for a particular prefix are
<glossterm>implementation-dependent</glossterm>.</impl></para>
</listitem>
</varlistentry>

| In 2.8.3.1, the value of "p:version": constraining this to xs:decimal
| is too much; I think it should be a string (actually xs:token), so
| that people can have versions like "1.0a" or "2.3.13".

Ok by me.

| In 2.8.3.3, I think the definition of p:iteration-count should be
| reworded to make it more declarative (and less procedural), so that
| parallel processors are possible. So instead of "the number of
| iterations that have occured", say "the position of the document being
| processed in the sequence of documents being processed".

Yes, that's better.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | I never wonder to see men wicked, but I
http://nwalsh.com/            | often wonder to see them not ashamed.--
                              | Swift