XML Processing Model WG

Meeting 44, 16 Nov 2006


See also: IRC log


Alex, Michael, Richard, Alessadro, Paul, Norm, Henry, Andrew


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/11/16-agenda.html


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.


Syntax of for-each/viewport/choose (match/select semantics)

Scribe describes the situation summarized in mail recent mail.

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.


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?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/11/30 17:14:36 $