W3C

XML Processing Model WG

Meeting 40, 19 Oct 2006

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Alessandro, Alex, Rui, Andrew, Mohamed, Richard
Regrets
None
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/10/19-agenda.html

Norm proposes to add "syntactic irregularity in choose"

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2006/10/12-minutes.html

Delayed until next week; scribe failed to post minutes.

Next meeting: telcon 26 Oct 2006

Mohamed gives regrets for 26 Oct.

Review of action items

A-13-01 continued

A-39-01 completed

Review of 13 Oct draft

Norm: Continued to next week.

Dynamically computed parameters

Alex: I wonder if I'm off in a corner by myself.

Murray: Yes, I think so.

Alex: Ok, but I note that we don't have any use cases in our requirements document that require computed parameters.

Norm: Any volunteers to produce some?

<scribe> ACTION: A-40-01 Richard to construct some use cases for computed parameters. [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action01]

<scribe> ACTION: A-40-02 Norm to construct some use cases for computed parameters. [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action02]

Murray: It seems to me that you can pick a use case that exists and add a sentence that says you get the parameters from a configuration file.

Alex: I think we need something much more complex in order to justify adding this large a feature.

Richard: We should have them as use cases so that we can say we don't need computed parameters for them.

<ht> Henry joins the call at 14 past the hour

Alex: I think the manifest case is covered by 5.6.

<richard> can someone paste in the url for the use cases

Norm: I concede that the alternative works but is perhaps more complex than most users would think of.

XProc use cases and requirements: ->http://www.w3.org/TR/2006/WD-xproc-requirements-20060411/

Murray: Alex has asked us to add to the use cases document, in terms of process do we need to do that?

Norm: No, we don't have to.
... but we should

Richard: How seriously do we have to take these use cases?

Alex: I think we should have a non-normative note that shows solutions to all of them.

Norm: I agree
... I propose that the editor be directed to add support for computed parameters to the language document.

Accepted.

<scribe> ACTION: A-40-03 Norm to update the language document to describe computed parameters [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action03]

Alex: We don't have the ability to compute a parameter on group.

Norm: We have declare parameter on group.

Alex: So that's going to allow step/source too?

Norm: Yes, I think so.

Henry: I'd be perfectly happy if we used parameter *everywhere* except declare-step-type (or whatever we called it)

Alex: Declare-parameter makes sense on pipeline.

Richard: There are three different things: 1. saying that some step has parameters; 2. saying what they are for some instance; 3. places where you have to do them both at once.
... Pipelines are in that third case.
... The same is true for group, for-each, and so one.
... We seem to have decided that you use declare-parameter for 1 and 3 and parameter for 2.

Norm: I think that's confusing, it means some things have declare and some don't.

Richard: Why do we have declare anywhere except component definitions?

Henry: You need to declare outputs that are then bound to inputs. You declare things that you can refer to elsewhere, then there are certain aspects of for-each and when that need to be declared.
... Input/output and declare-input/declare-output are much different than parameter/declare-parameter.
... I think the false parallelism that's there at the moment is already confusing.

Richard: What is the false parallel?

Henry: When you say declare-output on a when, that's there so that somewhere else some input can reference it. The source is always a declare-output. The only parallel for parameter would be to say that parameter has to refer to a declare-parameter.
... That's not true for group/when/for-each and such things.
... That seems very misleading.

Richard: Declare things declare either inputs, outputs or parameters.
... There are two things you then do, give values to them and the other is that use those values somewhere else. Parameters you use in XPath expressions. Output ports you use in declarations of input ports where you say where they came from. You declare them, assign to them, and use them. That's true of all three.

Henry: In the case of group, you declare a parameter but don't every seem to use it.

Alex: No that we've gone down this tangent; it seems like a number of people would like declare- to go away.
... At the f2f, I recall that there was an uncomfortable feeling about declare vs. use. We went around in circles and left it that way.

Henry: There are distinctions, I think we should reflect them, we don't have it quite right, I'm not in favor of removing them.

Richard: There are three things: I think it would be better to have 1 name for all three. Having 2 is bad and having 3 would be too verbose.

Alex: How many people on this call would prefer to drop declare-?

Richard: Is there any place where it would cause ambiguity?

Murray: Henry voiced his concern. As I recall Paul was the other person.

Paul: Which distinction?

Murray: I proposed an input element everywhere, things spread out, and when we contracted it back, that distinction remained.

Henry: I favor the distinction being preserved.

Straw poll: who's in favor of dropping the "declare-" prefix throughout.

Results: 8 in favor, 1 against, and 2 abstentions.

Paul: Why have things changed?

Norm: I think we struggled with the model at the f2f; many of us there were unhappy with the distinction. The best I can say is, time has passed.

Henry: I think part of the issue was that there were a lot of other alternatives on the table at the f2f.

We wonder what Jenni's position is? Norm recalls her being in favor of dropping the distinction.

Norm: I propose to produce a branch draft that loses the distinction and give folks a chance to see how it feels "in situ" as it were.

<scribe> ACTION: A-40-04: Norm to produce a draft that loses the distinction (and a diff) [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action04]

Murray: Can we discuss GRDDL at the end?

Norm: Yes.

GRDDL

Murray: I think there's some confusion based on the responses I've been getting.
... I'm asking about something not related to pipelines.
... An agent grabs a document and sees an GRDDL transformation. It also sees XInclude.
... Should it expand the XIncludes or not?
... I know we haven't talked about the other half of our charter much yet, but the GRDDL chair keeps asking me this question.
... Do we have anything to say.

Norm: I agree it's in our charter, so from a process point of view, I think the answer is "wait, we'll get to that as soon as we can".
... I think the spec should answer the question.

Murray: The problem is that the spec isn't written in terms of agents, only in terms of encoding.

Alex: Murray, how is this any different than someone saying that my transformation relies on the PSVI?
... That's a presupposition of XML Schema validation.

Henry: I think the answer is clear: in the absense of an answer about the default pipeline, there is no basis for GRDDL to take that question on.

<Zakim> MSM, you wanted to ask whether the right way to rephrase Norm's suggestion is "they say whether the GRDDL transformation gives the RDF meaning of the document as it exists or of

Michael: I understood Murray to say that Norm's answer is hard because the spec isn't written to talk about processors.
... I'm assuming that the spec says something like "the pointer to the GRDDL transformation is a pointer to a transformation that gives an RDF encoding of the meaning of this document"
... I think Norm's suggestion can be translated: "Does that transformation give the meaning of that document as it stands or the meaning of the document that can be obtained from the application of XInclude to this one"
... I'm with Norm in thinking you might want it one way or another, but I'm with Henry about the simplest thing that could be said.

Murray: What is the document as it stands?

Michael: If we're talking about any case where serialization/infoset isn't in the normal many-to-one relationship, that would need to be stated.

<ht> Murray: see http://dret.net/projects/xipr/ (a promissory note)

Richard: If you talk about the Infoset of the document, it seems to me that are referring to the output of the parser (no other processing).

Murray: In my mind, what you get after XInclude is part of the meaning of the document.

Alex: If you start with "the document as it stands" then when we answer part 2 of our charter, then you can say that "the document as it stands" is the output from that default processing.

<MSM> Murray, I would agree with you if you were talking about entity expansion. But the example we are talking about is XInclude, which gets used by people who want to be able to have, and work with, two different ESISes.

Syntactic irregularity of choose

Straw poll: does the syntactic irregularity of chooes/when bother you?

Results: 5 yes, 1 no, and 4 abstain

Norm: useful information.

Any other business

None.

Adjourned

Summary of Action Items

[NEW] ACTION: A-40-01 Richard to construct some use cases for computed parameters. [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action01]
[NEW] ACTION: A-40-02 Norm to construct some use cases for computed parameters. [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action02]
[NEW] ACTION: A-40-03 Norm to update the language document to describe computed parameters [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action03]
[NEW] ACTION: A-40-04: Norm to produce a draft that loses the distinction (and a diff) [recorded in http://www.w3.org/2006/10/19-xproc-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/11/01 15:19:19 $