See also: IRC log
Date: 19 Oct 2006
<scribe> Meeting: 40
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<rlopes> Zakim [IP is me
<rlopes> Zakim [IP is Rui
Telling Zakim who you are: http://www.w3.org/1998/12/bridge/info/name.php3
Norm proposes to add "syntactic irregularity in choose"
Delayed until next week; scribe failed to post minutes.
Mohamed gives regrets for 26 Oct.
<scribe> Continued to next week.
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.
<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.
<MoZ> I was saying yes
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]
<MoZ> MSM, what ?
Murray: Can we discuss GRDDL at the end?
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
... 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.
Straw poll: does the syntactic irregularity of chooes/when bother you?
Results: 5 yes, 1 no, and 4 abstain
Norm: useful information.
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/Accepted./Delayed until next week; scribe failed to post minutes./ Succeeded: s/No regrets given./Mohamed gives regrets for 26 Oct./ Succeeded: s/looses/loses/ Succeeded: s/Ye./Yes./ Succeeded: s/quesiton/question/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, PGrosso, Alex_Milowski, Alessandro_Vernet, [IPcaller], MoZ, Andrew, Rui, richard, Murray_Maloney, Ht, MSM Present: Norm Paul Alessandro Alex Rui Andrew Mohamed Richard Agenda: http://www.w3.org/XML/XProc/2006/10/19-agenda.html Found Date: 19 Oct 2006 Guessing minutes URL: http://www.w3.org/2006/10/19-xproc-minutes.html People with action items: a-40-01 a-40-02 a-40-03 a-40-04 norm richard[End of scribe.perl diagnostic output]