W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Minutes for XML Process Model WG telcon 2007-02-01

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Wed, 07 Feb 2007 10:34:36 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <878xfa2d83.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/02/01-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 53, 1 Feb 2007


   See also: IRC log[3]


           Norm, Paul, Alessandro, Rui, Henry, Richard, Alex, Andrew





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Review of editor's draft of last week
         4. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/02/01-agenda.html


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/01/25-minutes.html


   Face-to-face in 2007?

   Henry: I'll check if the W3C is ok with having a WG that runs for 18
   months without a f2f meeting.

   Richard: The rescheduled Tech Plenary is partly responsible.

   Paul: We had a f2f in August, and I thought we didn't plan to have a lot
   of f2f meetings.

   Norm: If we had a meeting, I think I would propose meeting in Europe,
   perhaps colocated with XTech in Paris or around the XML Summer School in
   Oxford in July?

   Henry: Edinburgh would be happy to host.

   Norm: Let's leave the question open for today, but we should decide soon.

   Another public WD in February?

   Norm: If review of last week's draft is generally favorable, I'd like to
   propose a new public WD in the next week or so then seriously consideer
   what obstacles prevent us from doing a Last Call in March.

  Review of editor's draft of last week

   -> http://www.w3.org/XML/XProc/docs/langspec.html

   a. Is the defaulting story right?

   Henry: Not quite: I can't find where we talk about the situations in which
   we write p:output with a binding.
   ... That's where there ought to be something about defaulting.
   ... You ought to not have to have an output.

   Norm: No, I didn't consider the defaulting case where you don't specify an
   output at all.

   Henry: I think we should.
   ... In particular, in 2.4, it's easy to read this as if it only worries
   about inputs.

   Norm: I'm going to take it as an editorial suggestion that 2.4 needs to
   say more about output bindings.

   Henry: Consider also 4.2.7: "The result of the p:for-each" ...

   Norm: And the defaulting story is...

   Henry: A container instance that has one of these inward/output facing

   Norm: If the container doesn't declare any output bindings, then it's
   output is what would have been input to a putative step that came after
   what is in fact the last step.
   ... Henry's email is:

   Henry: Consider figure 3
   ... Note that this pipeline has no p:output

   Richard: Is this what we want? Don't we want to be able to refer to the

   Alex: I didn't think we were going to default outputs

   Richard: I was assuming you would have defaults for outputs, but you'd
   have to declare the outputs.

   Alex: Where is this helpful? On viewport, for-each, etc.

   Henry: Can we look at figure 4 please?
   ... It should be clear where the input from the XSLT step comes from

   Richard: How do you declare a choose that has no outputs then?

   Henry: I'd be sorry if that obscure case required me to put outputs in
   every p:when

   Richard: I'd been assuming that you'd have to declare them, you just
   wouldn't have to bind them.

   Henry: I think that would just irritate users every time they had to do

   Richard: We can consider whether or not you have to declare them and
   whether or not you have to bind them separately.

   Norm: You could use a DevNull component to make a component that has no

   Henry: I really want to write pipelines like
   ... The flow is completely defaulted.
   ... I think the 90% case is where people will want to default the entire

   Richard: In order to get the abbreviated syntax you want, we're now having
   to change the unabbreviated syntax.
   ... It used to be clear that if you didn't have any outputs, there weren't

   Alex: So what's the name of the output of the choose?

   Norm: There isn't one. There's just an anonymous output that's only
   accessible as the default input to some following component.

   Henry: In the non-defaulted syntax, I think I'd be a little happier if I
   did have an explicit indication that the component didn't have any
   ... In particular, consider: unconnected outputs are not a bug, that's
   just fine. So I'm considering the case where someone writes a choose and,
   ignoring the defaulting discussion, does not put any outputs on any of the
   ... But the last step does have an output port.
   ... That seems to me to be a slightly odd situation. Any container that
   ends with a step that produces output in a container which doesn't have
   any outputs, I'd expect that to at least be a warning situation.
   ... That leads me to feel that I'd be perfectly happy to require
   components to explicitly state that they don't produce any outputs.

   Richard: I had not considered this question.

   Norm: Ok, let's leave this for a week and come back to it next week.

   Henry: In updating the DTD, I realized that there's an interesting
   difference between XPath context and input.
   ... Both have a binding, but only input allows a select attribute.


   Henry: My first thought was that that was ok, but then I thought about it
   a little longer and the following example occurred to me:
   ... I ended up thinking I'd rather write it that way.

   Norm: It seems reasonable to me.

   Some discussion of what happens when sequences are identified

   Alex points out the difference between the way select is proposed to work
   on xpath-context and the way it works on input.

   Henry: The paragraph that finishes "set of nodes is wrapped in a document"
   needs editorial improvement.
   ... If we accept my proposal, I think I do want select on xpath-context to
   work differently.
   ... Maybe we need to think about this for a while too

   Norm: Yes, probably.

   c. Do we want to do something similar about for-each/viewport?

   Norm tries to outline why the single input to viewport/for-each could or
   perhaps should also be anonymous.

   Henry: This is the thing which drives the process but isn't something that
   gets referred to subsequently.
   ... It's perfectly reasonable to have a different input. I think the
   simplest thing to do would be have an input with no port name.

   Alex: In the case of viewport, isn't the input often going to be

   Henry: I agree with Norm's analysis that giving it a name makes it
   available in which is odd.

   Alex: But you can't read from it inside.

   Richard: You could bind to it, just as you can bind to the inputs of a

   Alex: Is that how this works?

   Henry: If not, then it voilates the principle of least suprise at the very

   Norm: Taken together I think these three issues stand in the way of a
   public draft.
   ... Let's please resolve them next week

   Henry: Can you add my updated examples and the DTD to the draft?

   Norm: yes.

  Any other business?


Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/02/01-agenda.html
   [3] http://www.w3.org/2007/02/01-xproc-irc
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0014.html
   [8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/att-0014/fig4.xml
   [9] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0012.html
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.127 (CVS
    $Date: 2007/02/07 15:32:47 $

Received on Wednesday, 7 February 2007 15:35:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC