See also: IRC log
Date: 16 Nov 2006
<scribe> Meeting: 44
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Bill Bug?
-> http://www.w3.org/XML/XProc/2006/11/16-agenda.html
Accepted.
Scribe failed to post 9 Nov minutes; will approve at the next meeting
Regrets from Micheal, Henry
Henry: I'm happy
Approved for publication on 17 November.
http://www.w3.org/XML/XProc/docs/langspec.html
Scribe describes the situation summarized in mail @@@URI HERE@@@
Murray: Maybe we should have
moved the attributes off those elements.
... On subordinate elements, for example.
Norm: the other possibility is to move them up.
Henry: I think I prefer to move them up too.
Richard: Is it the case at the moment that input/output are the only thing that declare ports.
Henry: These elements are schizophrenic here.
Richard: Input on viewport is particularly strange on viewport because the select means something else.
Henry: I propose that the editor try it with the attributes on viewport/for-each/etc.
Norm: That would suggest resolving the syntactic ambiguity of foreach/viewport/choose by moving the attributes up.
Murray: Is there anyone who wants to move them down into input.
Michael: Maybe.
Richard: I can see your point,
but the place where the magic occurs here is on viewport and
putting more elements inside viewport doesn't seem like it's
going to help.
... It doesn't have the effect that a select has on a normal
input regardless of where it is.
... In this particular case, magic happens with the parts of
the document that aren't selected.
Norm: I'm concerned too.
Murray: Would it be reasonable to put a match attribute on viewport and leave the input?
Henry: I've been wondering that myself.
Richard: Would we then disallow the select attribute?
Murray: Why?
Richard: I imagine the viewport match as doing something to the whole document.
Henry: Then the input is really just the input.
Richard: If the input worked just like a normal input, that would be fine. But it ought not to be that the viewport element also specified the match and the internal name of the port.
Henry: We're circling around to where we were at Murray's place.
Norm: So the proposal is to have
the input just be a normal input and have two new attributes on
viewport to name the magic port and the match attribute.
... In this case, it would be reasonable to have select and
match and they would do the obvious thing.
... So would we do the same thing with for-each?
Alex: Sounds good to me.
Murray: So there'd be a double select?
Norm: Yes.
... Does this solve the choose problem?
Henry: No.
Murray: Since there's only one select/match on the outer element, can't we just give the port a magic name?
Norm: Magic name would work
because you have to name both the step and the port.
... I'm not see the value in giving a magic name.
Murray: Everywhere else you give a name, you do so on an input element.
Alex: That's a good point. We don't get to name ports.
Norm: I can go with that.
... Anyone have a problem with using a fixed name?
None heard.
Norm: Now we need names.
<ht> HST is happy with fixed names, not sure I like 'i'
Alex: I'll throw out "current"
Norm: I like current.
Richard: We have various standard
components that we've made up names for.
... Identity uses 'input' where others use 'document'.
... I usually imagine that there's a source and a result and a
stylesheet off on the side.
Alex: So, in this case also,
we're always going to have a document.
... If you took in a document, then I called the port name
'document'
... In viewport and for-each it's always a document, so we
could go with 'document'
<ht> I like 'source' better than 'input', but I also like 'document' when you know it _is_ a document
Richard: My only problem with 'document' is that it doesn't have any parallel with 'result' on output.
Alex: I was thinking we could come back to the general naming question later.
Norm: I think we're talking about the name of the port on p:input
Murray: The GRDDL folks wanted to
call things grddl-source and grddl-result. I had to point out
that there were really only documents. They might be used by
GRDDL, but that's not what they're for.
... I got them to change to input-document and
result-document.
<alexmilowski> Aside: I was confused. I was thinking we were talking about the inner output port name.
Murray: I understand that for some components, we have to differentiate the names.
Alex: I think viewport and for-each should both allow sequences.
Norm: I think we decided that they take single documents.
Alex: At least for-each has to allow sequences.
Richard/Henry: Yes
Henry: It must be the case that there is a way to iterate some subpipeline over a sequence of documents.
Murray: One vote against document.
Norm: Do you have a strong preference for 'input' over 'source'
Murray: Yes.
Richard: That would suggest that the output should be called 'output' not 'result'/
Henry: I have often considered that we ought to call both the primary input and output ports 'primary'
Some discussion of the status quo which outlaws that.
Norm: Murray has proposed the name 'input' for the input port of both for-each and viewport. Any objections?
None heard.
Norm: Alex has proposed the name 'current' for the "magic port" that subpiplines read from inside for-each and viewport. Any objections?
<ht> "subdoc"...
Henry: It doesn't speak to me. It makes a lot of sense for XSLT-weenies, but doesn't make any sense elsewhere.
<ht> Murray suggested "i"
Richard: We could call it "<>" as Perl does
<ht> dot
Norm laughs maniaccly
s/Maniaccly/Maniacly/
Norm: Can everyone live with current for the next draft.
Yes.
<scribe> Done\
Murray: How about 'this'?
<richard> "it"
<ht> "subtree"
Norm: The only thing we haven't made progress on is choose, but maybe they're similar enough to be ok.
Alex: Are we going to make these changes for 17 Nov?
Norm: No.
Alex: I think we should try to synchronise the standard components against them.
Norm: If we use input, should we use output.
Murray: It would help our
defaulting story if an unspecified name defaulted to some
default.
... I could go back and forth between source/result and
input/output.
... Maybe source/result is more evocative.
Norm: I'm torn.
... Straw poll: input/output or source/result
<ht> HST has to make a call on another line, prefers source/result, going on mute
Results: 7 prefer source/result and 2 prefer input/output
Norm: I propose we use
source/result in the next draft.
... Overriding our previous decision to use 'input'
Richard: Including standard components?
Norm: Yes.
... Any objections?
None heard.
None.
Adjourned.
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/concenred/concerned/ FAILED: s/Maniaccly/Maniacly/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Alex Michael Richard Alessadro Paul Norm Henry Andrew Regrets: Mohamed Agenda: http://www.w3.org/XML/XProc/2006/11/16-agenda.html Found Date: 16 Nov 2006 Guessing minutes URL: http://www.w3.org/2006/11/16-xproc-minutes.html People with action items:[End of scribe.perl diagnostic output]