- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 25 Jan 2007 15:29:57 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87lkjqg88q.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/01/25-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 52, 25 Jan 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Henry, Rui, Richard, Alex, Andrew
Regrets
Alessandro, Mohamed, Paul
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 1 Feb 2007
4. Choose/When syntax
5. Defaulting
6. Any other business
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/01/25-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/01/11-minutes.html
Accepted.
Next meeting: telcon 1 Feb 2007
No regrets given.
Choose/When syntax
Status quo: http://www.w3.org/XML/XProc/docs/alternate/[6]
Richard: Does the status quo allow you to override the context on each
when?
Norm: Yes, by using an input named "source".
Henry: I prefer option 2, but I'm not sure I'm happy with the name
xpath-context.
... But I'm increasingly unhappy with any aspect of our design that uses
builtin port names.
Norm: Tying this back to for-each and friends, the name "context" was
proposed.
... I think the context element is oddly named in the for-each case, but I
could get used to it.
Richard: What I find unpleasant is that the test is lexically outside the
context binding element.
... The context ought to be provided for things inside it or at the same
level, not for things outside it.
Norm: I see your point, but I don't know what to do about it.
Michael: I have a question of comprehension: I thought that context was
another name for a sole input.
Henry: That's not right: it's been an aspect of our choose/when design for
a long time that the input to the branches is distinct from the input
which is tested.
... You can test one document and process on each of the branches
different documents.
Michael: I think the draft should say that, I don't think it currently
does.
Alex: This context has the feature that we don't have to name the port.
... I would be really happy with a different name.
Norm repeats his earlier comments about the name "context"
Henry: I'm less sure that I want to treat this the same way that we treat
for-each and viewport.
... In those cases, the input there really is the input to the component.
... I really do want to stay with some consistent notion of what "the
input" is.
... I'm not sure we should fold them together.
... I like option 2 and I think calling it "context" is better than
"xpath-context"
Michael: I was with you up to the last part about the name.
Alex: For-each and viewport are exactly like choose/when.
... Viewport and for-each do something with the context.
Norm: Jeni made the point that having source in for-each and viewport is a
little odd.
Richard: I'm wishing that I'd taken a completely different approach and
using, for example, variables to refer to the documents in scope instead
of all the complexity of tests.
<MSM> +1 to HT's argument that the XPath context of a Choose/When is
conceptually quite different from the single input of a viewport or
for-each
Richard: It was suggested that XPaths be able to refer to inputs through
variables. So the test could be "$source/something" or
"$whatever/something".
Alex: We chould have an extension function to do this.
Norm muses "source(step,name)"
<ht> p:source(step,name)
<ht> p:pipe(step,name)
Alex: It has the consequence that it means you can't use an off-the-shelf
XPath implementation.
Richard: The problem with an extension function is that it means you can
dynamically construct the step and port names.
Henry: If that was the only thing in the way, we could just rule that out.
Richard: I disliked this before because it made it harder to see the flow
of documents through the pipeline.
... As long as you can figure out where the pipes go at compile time, I
could live with it.
Henry: What I like about this is that it invites a natural default which
is that the context of when defaults to context of choose which defaults
to the primary input of choose.
Norm: With my chair's hat on, I have to question the size of this change?
Richard: I think that over the last few months, this nagging problem of
the syntax and how to bind things for XPaths has been dragging us back.
... Maybe it is a big enough problem that we really do need to reconsider
it.
Henry: Opening XPaths in general to being able to attract input from any
in-scope output port inside square brackets, etc. really does change the
power of the language as it appears.
... It effectively changes your ability to read off the data flow of a
pipeline from its input port elements.
... Extension functions have semantics that go way beyond the problem we
were trying to solve.
... I'm back to thinking we should go with option 2 and discuss the name
of the element at another time.
Michael: My problem with option 2 is for the same information it requires
a more complicated and elaborate XML structure. You're adding element
structures that don't seem to be doing much. The term context is already
taken in our spec.
... We're going to have different names for these things.
Alex: Couldn't we just have an input without a port attribute?
Henry: That's just too complex for users.
... Option 2 spells a special case with a special element name instead of
spelling it "input port='source'"
Michael: Looking at the example more carefully, I think you're right. The
second option isn't more complex.
... I withdraw the argument.
Micheal: My dislike of adding a new GI was based on the misaprehension
given by the note in the November draft that said that context was
analogous with the input of for-each which I'm now learning is not what
people intend.
... I still stick at the term "context"
<MSM> Henry, your argument does not support the use of the term "context"
to mean something that the XPath spec calls by a different name
<ht> 'context-node' works for me
Norm: I think that option 2, if we stick with something like the current
syntax, is a consensus position. Does anyone disagree?
No one did.
Norm: So the question is then, what name? We can always revisit it later.
<MSM> if we find a different name for what is now called 'context', we can
revisit the name of this element.
Norm: The name is left to the editor's discretion, except that "context"
is off the table.
Proposed: We will adopt option 2 as described above for the next draft.
Accepted.
Defaulting
<ht>
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0022.html[7]
Henry: Yes. I had in mind going back to the threads that started in
December.
<ht>
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0041.html[8]
<ht>
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0056.html[9]
Henry: I would like to say something like where we ended up in that
discussion, editor please draft :-)
Norm: The editor might like somewhat more direction.
Alex: The real crux seems to be dealing with the preceding sibling case.
Henry: A crucial question is, is it names or is it arity? I started out
thinking that I didn't care what a step's port was called if it only had
one.
Norm: I think the draft will be easier to understand if we do it in terms
of names.
Henry: I think it's easier to talk about the single input port, regardless
of name.
Richard: We could certainly say that if the component only has one input,
that's it's default.
Alex: Or we could say that a component declaration indicated its default
port.
Richard: I like that.
Some discussion of input ports
Richard: I think you could just say that any unconnected input port is
connected to the default.
Alex: In the case of building tools, I can imagine that having a
declaration of which one is usually defaulted would be useful.
Richard: I can see Alex's point that this would be useful for a graphical
tool
<ht> I'm now convinced that the only thing we need to do is provide a rule
for which output provides the default input binding for its following
sibling in the case where there is more than one output port
Richard: We could say that you designate one input as primary but that
it's not used by the language.
<alexmilowski> +1
Norm: I think we're saying that, component declarations should be allowed
to specify a single primary output, they should be allowed to specify a
single primary input (but the language doesn't care) and that any
unconnected input is automaticly connected to the default input.
... Where the default input is the default output of the preceing sibling
or the preceding sibling of the container.
... Recursively.
Richard: I would say that each container component should specify what
it's default input is and that's in the context.
... I also think we should say explicitly that a component only has one
output, that is it's default output regardless of what we say in the
declaration.
Any other business
None
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/01/25-agenda.html
[3] http://www.w3.org/2007/01/25-xproc-irc
[6] http://www.w3.org/XML/XProc/docs/alternate/
[7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0022.html
[8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0041.html
[9] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0056.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
log[11])
$Date: 2007/01/25 20:18:58 $
Received on Thursday, 25 January 2007 20:33:08 UTC