XProc Last Call Comments

+1,5

Mohamed

On Mon, Mar 31, 2008 at 10:46 PM, Alessandro Vernet <avernet@orbeon.com> wrote:
>
>  On Mar 31, 2008, at 3:38 AM, Henry S. Thompson wrote:
>  > Shall I ask W3C to set up xproc-dev, same basis as xmlschema-dev,
>  > i.e. public archives, open subscription, only subscribers can post?
>
>
>  +1
>
>  Alex
>  --
>  Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
>  Orbeon's Blog: http://www.orbeon.com/blog/
>  Personal Blog: http://avernet.blogspot.com/
>
>
>



-- 
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 €

On Mon, Apr 14, 2008 at 9:42 AM, Norman Walsh <ndw@nwalsh.com> wrote:
>  I don't follow. Our strategy for document inputs names them "source"
>  and "result" and makes it an error to attempt to define another port
>  with those names. Are you suggesting that we should do the same thing
>  for parameter inputs? Or are you suggesting that an implicit parameter
>  input port doesn't need a name, and so cannot be explicitly
>  referenced?

I am suggesting that since p:declare-step doesn't declare implicit
document input ports, it shouldn't declare implicit parameter input
ports either (as described in section 2.9).

And as far as p:pipeline is concerned, since it already automatically
declares the "source" document input port and "result" document output
port, I have no problem saying that it also automatically declares a
"parameters" parameter input port.

Does this make sense?

>  It does. The tableaux at the beginning of 5.1.2 specifies it and the
>  fourth paragraph below that explains it. Doesn't it?

Yes, it does. Somehow its didn't occur to me that 5.1.1 was
specifically about document inputs. My bad.

Alex
-- 
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
Personal Blog: http://avernet.blogspot.com/

/ Toman_Vojtech@emc.com was heard to say:
[...]
|> > I find now that I want to refer to the pipeline input. I can't put
|> > a name up there, so I have to invent a namespace and a type:
|> 
|> No you don't (I didn't in _my_ example [1]):
|> 
|>  <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
|>              type="mypipe">
|> 
|> ...
|> 
|>        <p:pipe step="mypipe" port="source"/>
|> 
|> is all you need.
|> 
|> ht
|
| Is it really so? I had a similar problem, but I came to the conclusion
| that you always have to use a non-null namespace in the "type" attribute
| - simply because p:pipeline is just a special case of p:declare-step,
| which demands that type is in a non-null namespace.

Right you are! I thought we'd made that restriction, but didn't find it
at the time.

So. We're back to having awkward irrelevant namespace declarations in
order to refer to the inputs of a pipeline explicitly, or we're
removing the "no null namespace" restriction.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Clearness is so eminently one of the
http://nwalsh.com/            | characteristics of truth that often it
                              | even passes for truth itself.-- Joubert

Ok digging through I find some problems I see at first glance :

It is said

[[ The p:documentation<http://www.w3.org/XML/XProc/docs/langspec.html#p.documentation>element
is not shown, but it is allowed anywhere. ]]

but it is explicitely shown in the production of sub-pipeline

Please remove it from there, it is confusing

-----

Please do the same for p:pipeinfo (I mean when the FIXME will be filled)

-----

One point I'm doing most of the time is documenting an input, and I want, if
I remove the input, that the documentation will be considerate as no more
accurate

I propose for that purpose, to add to p:documentation an new attribute
@refid which should refer to the value of an @xml:id attribute which provide
the ability to properly document pipeline and to have a security in case, I
suppress the element I was documenting (then the @refid would point to
nothing) which could be given as a warning by an XProc processor in a
interoperable way

-----

Ok let's me try to arrive to the end of the path, I sketched

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

(note that I remove p:pipeinfo and p:documentation since they can appear
everywhere)

If we say that

the context of evaluation of p:variable is composed of the option that are
declared before and all but the step of the siblings output port


Mohamed

On Thu, Mar 20, 2008 at 5:29 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> / Innovimax SARL <innovimax@gmail.com> was heard to say:
> | instead of this
> |
> | subpipeline = (p:for-each
> | |p:viewport |
> | p:choose |p:group
> | |p:try |p:*atomic*
> | |*pfx:user-pipeline* |
> | p:documentation|p:pipeinfo|p:variable)*
> |
> | can we try
> |
> | subpipeline = (p:variable|p:documentation|p:pipeinfo)*,(p:for-each
> | |p:viewport |
> | p:choose |p:group
> | |p:try |p:*atomic*
> | |*pfx:user-pipeline* |
> | p:documentation|p:pipeinfo)*
>
> I don't think that would be sufficient. You could still say:
>
> <p:variable name="data" select="//p[1]">
>  <p:pipe port="result" step="fw"/>
> </p:variable>
>
> <p:xslt name="one">
>  <p:input port="source" .../>
>  <p:input port="stylesheet" .../>
>  <p:with-param name="data" select="$data"/>
> </p:xslt>
>
> <p:xslt name="fw">
>  <p:input port="stylesheet" .../>
> </p:xslt>
>
> which is horribly circular. I think the simplest solution is to say
> that it is a static error if the xpath context of a p:variable refers
> to any step that is among its siblings.
>
> Saying that the xpath context of a p:variable is always an empty
> document strikes me as too limiting.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh  | You must not think me necessarily
> http://nwalsh.com/            | foolish because I am facetious, nor
>                              | will I consider you necessarily wise
>                              | because you are grave.--Sydney Smith
>



-- 
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 €

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

Norman Walsh writes:

> I think that's where we wound up back when we decided to take
> pfx:other-compound-step out of 4.7, 
>
>   http://www.w3.org/TR/2007/WD-xproc-20070706/#p.other

A primary motivation for my lengthy re-analysis was because it
re-surfaced in the alternate draft, and is still there today [1]:

 "The presence of other compound steps is implementation-defined;
  XProc provides no standard mechanism for defining them or describing
  what they can contain."

> | Phew!
> |
> | _If_ we accept this analysis and its conclusion, I think I know what
> | 2.1 and 4.7 should look like . . .

See next message.

[1] http://www.w3.org/XML/XProc/docs/langspec.html#p.atomic
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, 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)

iD8DBQFH4TXQkjnJixAXWBoRAiU/AJ9g/dR8Tt4vLutVQcHDHOx1eAJquACcDoiW
81uzdcRsQ9P68SWBLhKBJls=
=PE5S
-----END PGP SIGNATURE-----

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| What about doing what XSLT does and having a p:fallback element that
| must be present in any extension/Vnext compound steps. If the
| processor encounters an unknown element, it must execute the
| p:fallback child of that element if it has one. If it doesn't have a
| p:fallback child then it's a static error.

We could, I guess.

| I'm generally happy to go along with (4) if there's no other
| acceptable way, though I'm not happy that it means that if a new
| compound step is introduced in Vnext, people won't be able to use it
| in their pipelines without making their pipelines unrunnable in v1
| implementations.

It would.

| Actually, to just deal with Vnext compound steps, couldn't we use the
| forward compatibility rules: make unknown elements dynamic errors in
| forwards compatibility mode and static errors otherwise.

No, I don't think so, because static analysis can't be performed in
the face of unknown compound steps. The processor has know way to know
what its inputs and outputs might be.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It would not be better if things
http://nwalsh.com/            | happened to men just as they wished.--
                              | Heraclitus

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

Jeni Tennison writes:

> What about doing what XSLT does and having a p:fallback element that
> must be present in any extension/Vnext compound steps. If the
> processor encounters an unknown element, it must execute the
> p:fallback child of that element if it has one. If it doesn't have a
> p:fallback child then it's a static error.

Well, I feel like compound steps are more like XSLT top-level elements than
XSLT instruction elements.  You can't extend XSLT with a new kind of
template, for example.

> I'm generally happy to go along with (4) if there's no other
> acceptable way, though I'm not happy that it means that if a new
> compound step is introduced in Vnext, people won't be able to use it
> in their pipelines without making their pipelines unrunnable in v1
> implementations.

Well, that's exactly what would happen if XSLT ever introduces a new
kind of template.

> Actually, to just deal with Vnext compound steps, couldn't we use the
> forward compatibility rules: make unknown elements dynamic errors in
> forwards compatibility mode and static errors otherwise.

Hmm.  I'm not sure treating p:foreach one way in normal mode and
another in forward compatibility mode is a service to users. . .

> (Isn't this what 2.9 Versioning Considerations says already?)

I don't think so -- you can only avoid the static error if there's a
p:declare-step for your element in the Vnext canonical library.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, 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)

iD8DBQFH4TeMkjnJixAXWBoRAs4DAJwKmwk/jVXYW3zaay9POIQrBpetAACfaXpq
XqIPGe/ssxZNqydzDKDT/FI=
=TzlB
-----END PGP SIGNATURE-----

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| As promised, I've tried to draft a proposed change to 2.1 and 4.7 wrt
| all this.  I've actually produced this as a way-cut-down alternate
| draft [1], as the formatting is sufficiently complex/important to need
| to be seen in full to be comprehensible.  Please try to have a look
| before tomorrow's call.

It doesn't appear that much different to me, though maybe I can no
longer see the forest for all the damn trees. I do find the repeated,
essentially identical, tableaux more confusing rather than less,
however.

| After all the discussion about non-standard compound steps, all I've
| done to implement my preferred option (4) is _remove_ any way they
| could sneak in.  If we feel more is necessary, a Note along the lines
| of "It follows from the above that there is no provision for
| backwards-compatible introduction of new compound step types." could
| be added.

Hmm. I'll look again tomorrow morning, I'm getting EBRAINFULL errors,
I think.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Puritanism--The haunting fear that
http://nwalsh.com/            | someone, somewhere may be happy.--H.L.
                              | Mencken

I have not looked at any of this for a while, so my take may be way off base,
but maybe I am better able to see the trees, even if I don't know the forest
all that well.

I had difficulty parsing the whole sub-section.

First of all, I wondered what "Other Steps" meant as a title in the TOC
of the editor's draft. I see that "Atomic Steps" is used in the Redux version.
I never felt that I understood why the term "Other Steps" was chosen
to represent exactly. It seems to posit the existence of a separate class
of steps which are to be know henceforth as "Other" where perhaps
"Xeno Steps" might more evocatively express the intent. Perhaps it
means "Extension Steps." Or perhaps "Other" has some more subtle
meaning that simply escapes me. The point being that I got caught on this,
so maybe others will too.

I did alright after that, think that I knew what was going on, and then
I got to the two "If the step element name ..." parts and I wondered if
I was able to parse those sentences successfully. I decided in the end
that I could not, and speculated that I might not be alone. I thought
that I might have done better if I had seen an example of correct and
incorrect.

I think that I think that I might know what this section is about, but it sure
is not clear by reading it in isolation.

I think that I want to read a title that contains the words "Extension" and 
"Step(s)".
I think that I want a paragraph to explain how one approaches extending xproc,
whether sanctioned or not, and what the implications of that are on both
processor development and pipeline development -- design your pipeline with
your processor in mind, design your processor with your documents in mind,
or design your pipelines for lowest common denominator. We have to address 
this.

I understand that I haven't offered any constructive criticism. I'll try to 
have
something more helpful to say tomorrow morning.

Regards,

Murray

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| SotD: Needs to be brought up to date. . .
|
| 1, just after Figure 1: "list of W3C XML Schemas" -> "sequence of W3C
|                         XML Schema documents"

Fixed.

| Example 2  Why not use p:pipeline and get rid of the source and result
| 	   ports?

Ok.

|
| Example 3  Leave step names out?  They're not doing anything . . . You
|            switch to p:pipeline here, w/o any explanation: I
|            definitely now think the switch should come earlier, with
|            something like "For pipelines with one input and one
|            output, p:pipeline can be used instead of p:declare-step,
|            and input and output declarations are provided by default."

Yes.

| 2.         (last para before 2.1) Maybe add something along the lines
|            of "The pattern of connections between steps will not
|            always completely determine their order of evaluation: the
|            evaluation order of steps not connected to one another is
|            _implementation-dependent_."

Ok.

| 2.1        [Climbs back on old hobby-horse] The pseudo-production for
| 	   subpipeline contains 'pfx:other-step', which links to a
| 	   section labelled 'pfx:other-atomic-step'.  Shouldn't the
| 	   production have 'p:standard-step|pfx:user-pipeline, and both
| 	   link tableaux at the top of 4.7, which should be called
| 	   *Atomic Steps*, and should begin "Other steps are specified
| 	   by elements that occur as _contained steps_, invoking either
| 	   standard (built-in) steps or user-defined pipelines:"
| 	   followed by two tableaux, one for pfx:user-pipeline and one
| 	   for p:standard-step, each otherwise the same as the existing
| 	   pfx:other-atomic-step.  (Other comments about 4.7 below)

I'll meet you half way :-) I tinkered with the links in subpipeline,
renamed 4.7, and tinkered with the prose and the tableux, but didn't
duplicate the tableux.

| 2.1        After the para after the pseudo-production, how about "On
|            the other hand, p:user-pipelines are treated as
|            atomic---although a pipeline _definition contains a
|            subpipeline, a step which invokes a user-defined pipeline
|            does not."

I did something like that. The para immediately after the
pseudo-production actually no longer makes any sense given the
adoption of multi-container step terminology.

| 2.1.1      I'm still not happy with when/choose/catch having names.
|            This would appear to allow me to write e.g.
|
|            <p:choose>
|             <p:when name="never" test="1=0">
|              <p:output name="result"/>
|              ...
|             </p:when>
|             <p:when>
|              <p:xpath-context>
|               <p:pipe step="never" port="result"/>
|              </p:xpath-context>
|             . . .
|
|            </p:choose>
|
|           but that's clearly incoherent.  The situation wrt how the
|           containers/pseudo-steps interact with the environment rules
|           needs to be clarified.  I think we can't maintain the
|           current attempt to shoehorn them into a strict
|           step/step-container duality.

Ok. I'm willing to float the idea that only steps (atomic, compound,
or multi-container) have names.

Then we get to p:group and I start to think that maybe we should just
say to heck with it and have p:trycatch/p:try/p:catch.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Men are more like the times they live
http://nwalsh.com/            | in than they are like their
                              | fathers.--Ali Ibn-abi-talib

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

Argggghhhh!  Somewhere in there I accidently switched back to the Feb
8 draft.

I think all the comments still stand, but may require a bit of work to
locate properly. . .

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, 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)

iD8DBQFH3qVikjnJixAXWBoRAqSRAJ9WIXK7pHEjyXMnfVP3S8x/y/nofQCdFV95
vCaDhQcBnv1/vpCcMv/J7wc=
=w1qE
-----END PGP SIGNATURE-----

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 2.2      "All atomic steps are defined by a p:declare-step. The
|          declaration of an atomic step defines the input ports, output
|          ports, and options of all steps of that type."  --> "All
|          atomic step types are defined by a p:declare-step. The
|          declaration of an atomic step type defines the input ports,
|          output ports, and options of all steps of that type."
|
|          I think it's worth being pedantic about this at the
|          beginning, but I'm _not_ going to make comparable suggestions
|          throughout the rest of the spec.

Good, because if you are too agressive on that point, someone's going
to suggest that we rename declare-step to declare-step-type and then
we'll spend four telcons arguing about it.

| 2.2      "In the very simplest case, the declaration is implicit, but"
|          Hunh?  When is a pipeline every not explicitly declared?  I
|          think removing this would be just fine. . .

It's implicit in the p:pipeline case where there are no explicit
declarations for the source and result ports.

But I'm content to remove it as well.

| 2.2      Is this the right place to mention that a single output can
|          be multiply connected?  We haven't said it yet (I don't
|          think), and it would be very easy to start assuming that
|          there was a one-to-one constraint, in the absence of anything
|          to the contrary.  Something like "An output port may be
|          connected to more than one input port.  At runtime this will
|          result in distinct copies of the output." just before the
|          definition of _signature_.

Done.

| 2.2      "The error output port is only bound to an input in the catch
|          clause of a try/catch." -> "Error output ports are un-named,
|          and only accessible via the automatic connection made from
|          them to the primary input of the *p:catch* subpipeline of an
|          immediately containing *p:try/p:catch*"

Ok.

| 2.2      Given that the final discussion in this section about URI
|          indeterminacy is dealing in double negatives already, is
|          this the place we should also acknowledge that it's
|          implementation-defined whether XQuery/XSLT-2.0 rules for
|          guaranteeing consistency across multiple references to the
|          same URI are provided or not?

I added a para just before the note.

| 2.4      A _bit_ more is needed here, or 2.8 is at best difficult to
|          read and at worst incomprehensible.  A para. about the
|          difference between option declaration and option binding,
|          with one example each of select= and value=, perhaps. . .

I'm not sure what section you're actually referring to here...and I'm afraid
I screwed up and checked in the 'alternate' draft on top of the old one.
My bad.

| 2.7      "[Definition: The readable ports are the step name/port name
|          pairs that are on steps in the same scope.]"  This is too
|          narrow, there are other readable ports, as set out just
|          below.  I think it's sufficient to just say "[Definition: The
|          readable ports are a set of step name/port name pairs.]"

Ok.

| 2.7      See my earlier message for what amounts to a suggestion for
|          changes to this section.

Uhm. I replied to the earlier message so I guess I've addressed these.

| 2.8.1 and 2.8.2 "Current dateTime
|
|                    An implementation defined point in time."
|          -->
|          "Current dateTime
|
|            An _implementation defined_ point in time."

Ok.

| 2.8.3    "The XProc processor must support" --> "The XProc processor
|           *must* support"

Got it.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Where it is permissible both to die and
http://nwalsh.com/            | not to die, it is an abuse of valour to
                              | die.-- Mencius

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 2.4      This is a _huge_ and complex section and completely derails
|          the momentum of a reader who still hasn't gotten to the basic
|          pipeline syntax.  I think it worked better down in section 5
|          where it used to be. . .

Well. Ok. I'll try that. I didn't like the way it came out when I was
using the machete, but maybe I can reformulate it a bit.

| 3        The Note at the beginning of this section is quite bizarre --
|          what is it trying to tell us?  Do we really need it?

I don't think so.

| 3.1      associed --> associated

Fixed.

| 3.2      Maybe useful to add here something like "Step types,
|          variables, options and parameters are named with QNames;
|          steps and ports are named with NCNames".

Done.

| 3.7      "any other conformant XProc processor would produce" -->
|          "would arise in the absence of the attribute"; "a conformant
|          processor is required to signal" --> "would be signalled in
|          the absence of the attribute"

Much better, thank you.

|          The final sentence is confusing at best and should probably
|          be removed: being implementation-{defined,dependent} doesn't
|          _ipso facto_ keep you from sinning in one of the two ways
|          specified above.

Ok.

| 4.1      "e.g., ones that are provided" --> "e.g. ones that contain an
|          explicit subpipeline, or are provided"

Ok.

| 4.1      No p:variable allowed?  Ah, I see -- no p:variable allowed
|          _anywhere_ :-).  I take it the syntax hasn't been updated
|          yet. . .

p:variable is allowed in subpipeline. And now at the beginning of p:choose
and p:try.

|          I would vote for allowing p:variable in the prologue of any
|          container, meta-container, p:pipeline or p:declare-step.

I don't think we want to allow variables to be mixed in with the other
prologue elements. 

In particular, if we allowed a variable to occur before a parameter,
we'd have to restrict the variable in ways that we don't if we just
let it come after.

| 4.1      I think the duplication between this and p:declare-step is
|          unnecessary.  I would suggest removing
|          * The third paragraph
|          * Everything after the first para. after the tableau down
|            through para which begins "If a step within the
|            _subpipeline_ needs".

Works for me!

| 4.2      "If the iteration source for a p:for-each is an empty
|          sequence, then" --> "If the iteration source for a p:for-each
|          is an empty sequence, then the subpipeline is never run and"

Fixed.

| 4.2      "If the p:for-each has a primary output port and . . ." --
|          it's not clear from this whether the defaulting rule from the
|          end of section 2.3 applies before this clause, as it were.
|          Surely it is meant to, so I would suggest --> "If the
|          p:for-each has a primary output port (explicit or supplied by
|          default (see [ref. 2.3]) and"

Yep.

| 4.3      "The p:viewport must contain a single, primary output port."
|          Why is p:viewport different from p:for-each in this regard?
|          Or rather, it's easy to read this as implying that every
|          p:viewport must contain an _explicit_ p:output.  Again, I
|          presume that's not what's meant, so suggest --> "The
|          p:viewport must have a single, primary output port, either
|          declared explicitly or supplied by default (see [ref. 2.3])."

Ok.

| 4.4.2    "effective boolean value is the guard expression" -->
|          "effective boolean value is the guard"

Ok.

| 4.6      (minor niggle): s/result/output/ throughout, perhaps?
|          Compare 4.4 (which does have _one_ 'result', I admit :-(

Sure and not anymore, respectively. :-)

| 4.7      We've given ourselves an upgrade path for adding new
|          built-in/standard atomic steps, but we haven't done so for
|          new compound steps.  I'm not happy with my earlier
|          'hobby-horse' comment on the 'subpipeline' pseudo-production
|          in section 2.1, either.  I guess I'll send a separate message
|          about this whole mess. . .

Yes, please. I recall that you argued for *removing* the bits of the
spec that attempted to be more open about compound steps. But maybe
that's because they weren't very clear.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is seldom that any liberty is lost
http://nwalsh.com/            | all at once.--David Hume

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 2.4      This is a _huge_ and complex section and completely derails
|          the momentum of a reader who still hasn't gotten to the basic
|          pipeline syntax.  I think it worked better down in section 5
|          where it used to be. . .

Ok, I've reorganized things. Note, however, that this totally *blows* all
the section numbers from these messages :-(

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Great success is commoner than real
http://nwalsh.com/            | abilities.-- Vauvenargues

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 5.1.1    "and my provide" --> "and may provide"

Fixed.

| 5.1.1    'provides a single document, but
|
|            <p:identity name="irrelevant">'
|
|          So irrelevant that it should be removed, I think. . .

Right.

| 5.1.2    "Most stylesheets don't bother" --> "Most steps don't bother"

Fixed.

| 5.1.3    "It is a static error (err:XS0023) for a p:pipe to appear in
|           a default binding."  Why is this necessary?  The tableau for
|           input declarations doesn't include p:pipe, so XS0044 does
|           the necessary, doesn't it?

5.1.3 is in the wrong place; it should be at the end of 5.1.1.

| 5.4      "A p:output identifies an output port, optionally declaring it, if
|          necessary." --> "A p:output declares an output port,
|          optionally binding and input for it, if necessary."

Ok.

| 5.4      "It is a static error (err:XS0013) if the port given does not
|          match the name of an output port specified in the step's
|          declaration."  Either I'm confused, or this (and XS0013)
|          should be removed.  You _can't specify_ an output on an
|          atomic step, which is the only case where a separate
|          declaration is availale to compare it to.

Right. Wow, that's been hanging around for a few drafts, eh?

| 5.7.2    The discussion of defaults is not quite right yet, I don't
|          think.  It appears to me to contradict itself about whether
|          the values of variables which are in scope for a step type
|          instance which needs a default are available or not.  Here's
|          my proposed rewrite, assuming xsl:param is the appropriate
|          model:
|
|     If an option is not declared to be required, it may be given a
|     default value. The value can be specified in two ways: with a
|     select or value attribute.
|
|     It is a static error (err:XS0017) to specify that an option is
|     both required and has a default value.
|
|     If a value attribute is specified, its literal content supplies the
|     default value of the option.
|
|     <p:option
|       name = QName
|       value = string />
|
|     If a select attribute is specified, its actual value supplies the
|     default value of the option, which may differ from one instance of
|     the step type to another.
|
|     <p:option
|       name = QName
|       select = XPathExpression />
|
|     The select expression is only evaluated when its actual value is
|     needed by an instance of the step type being declared. In this
|     case, it is evaluated as described in Section 2.7.3,
|     p:with-option, except that the *context node* is an empty document
|     node and the *in-scope namespaces* are the in-scope namespaces of
|     the p:option itself.
|
|     When XPath 1.0 is being used, the string value of the expression
|     becomes the value of the option; when XPath 2.0 is being used, the
|     value is an untypedAtomic.

Ok. But I also left in these two paragraphs because I think they make
an important point:

<para><error code="S0019">It is a <glossterm>static error</glossterm>
if the <tag class="attribute">select</tag> expression contains a
variable reference that uses a QName that is not the name of an
in-scope option.</error></para>

<para>Note that because the in-scope options and variables of a
declared step are initially empty, the context in which the instance
occurs can have no bearing on the default value of any options. Only
the values of preceding options can be referenced from the select
expression.</para>


| 5.7.3    Similarly, the second para after the tableau in this section
|          needs to change to something like the following:
|
|          Also, retrospectively, we need to add bindings back in to the
|          Environment and defining *in-scope options* and *in-scope
|          variables* with reference thereto -- see separate message.

I don't think you've sent that message yet.

|     The values of options for a step *must* be computed in the order
|     determined by the step's _signature_.
|
|     If a select expression is given, it is evaluated as an XPath
|     expression using the context defined in Section 2.6.1, Processor
|     XPath Context, for the surrounding step, with the addition of
|     variable bindings for all options whose declarations precede its
|     declaration in the surrounding step's _signature_.
|
|     When XPath 1.0 is being used, the string value of the expression
|     becomes the value of the option; when XPath 2.0 is being used, the
|     value is an untypedAtomic.

I think I did the right thing. I could be wrong. :-/

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The offhand decision of some
http://nwalsh.com/            | commonplace mind high in office at a
                              | critical moment influences the course
                              | of events for a hundred years.--Thomas
                              | Hardy

> / Toman_Vojtech@emc.com was heard to say:
> | The specification uses the 'href' attribute for referring 
> to external
> | content (p:document) or external locations (p:load, 
> p:store, p:log). It
> | is also used in c:error and c:request elements. I wonder if this
> | attribute shouldn't be renamed to 'uri' which I think would a more
> | adequate name. 
> 
> Yes, it would be a better name, but the convention across XML 
> vocabulares
> (XInclude, XSLT, XML Schema, etc.) is to use 'href'. It 
> seems, to me, that
> we're better off being consistent on this point than right :-)
> 

OK, but then perhaps p:xsl-formatter should use 'href' as well, instead
of 'uri'? :)

Vojtech

--
Vojtech Toman
Principal Software Engineer
EMC Corporation

Aert van Nesstraat 45
3012 CA Rotterdam
The Netherlands

Toman_Vojtech@emc.com

On Wed, Feb 20, 2008 at 5:22 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
>
> | I see there is a FIXME note by p:pipeinfo ... isn't p:documentation
>  | sufficient enough to remove this element?
>
>  No. The pipeinfo element takes the place of "ignorable elements". It's
>  for application-goo, machine readable stuff, not documentation.

cricky, didn't grok this one at all ... which is why I guess the fixme
note says 'expand'

I will wait to comment further until I see expanded text.

J

On Feb 12, 2008 1:59 PM, Vasil Rangelov <boen.robot@gmail.com> wrote:
>
> Isn't that already the case?
> Look at 4.6.1.2: c:error - http://www.w3.org/XML/XProc/docs/langspec.html#cv.error

I have used c:error, in my xproc implementation, just for p:error step

seeking clarification for p:error step not static/dynamic errors
thrown by xproc processor .

cheers, Jim Fuller