- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 16 Nov 2006 12:28:57 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <874pszuwpy.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/11/16-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 44, 16 Nov 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Alex, Michael, Richard, Alessadro, Paul, Norm, Henry, Andrew
Regrets
Mohamed
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Next meeting: telcon 30 Nov 2006 (23 Nov is U.S. Thanksgiving)
3. Technical agenda
4. Review of the 17 Nov draft
5. Syntax of for-each/viewport/choose (match/select semantics)
6. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> 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
Next meeting: telcon 30 Nov 2006 (23 Nov is U.S. Thanksgiving)
Regrets from Micheal, Henry
Technical agenda
Review of the 17 Nov draft
Henry: I'm happy
Approved for publication on 17 November.
http://www.w3.org/XML/XProc/docs/langspec.html[5]
Syntax of for-each/viewport/choose (match/select semantics)
Scribe describes the situation summarized in mail recent mail[6].
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
Norm: LOL!
<ht> dot
Norm: Can everyone live with current for the next draft.
Yes.
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.
Any other business?
None.
Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/11/16-agenda.html
[3] http://www.w3.org/2006/11/16-xproc-irc
[5] http://www.w3.org/XML/XProc/docs/langspec.html
[6]
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0051.html
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.127 (CVS
log[8])
$Date: 2006/11/16 17:25:03 $
Received on Thursday, 16 November 2006 17:57:01 UTC