XML Processing Model WG

Meeting 29, 20 Jul 2006


See also: IRC log


Rui, Paul, Alex, Richard, Alessandro, Norm, Murray
Mohamed, Henry, Andrew


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/07/20-agenda.html


Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/06/29-minutes.html


-> http://www.w3.org/XML/XProc/2006/07/13-minutes.html


Next meeting: 27 July

Any regrets?

Paul is at risk.

Face-to-face: 2-4 Aug 2006.

Registration is closed. Make sure your arrangements are in order.

Murray: Temperatures for the f2f are likely to be warm. It's been in the 80's.

Review of open action items

A-27-01: Alex to write up some straw syntaxes for some of the use cases

<scribe> Closed.

A-27-02: Norm to write up some straw syntaxes for some of the use cases

<scribe> Closed.

A-23-02: Richard to write a syntax proposal

<scribe> Continued.

A-23-03: Norm to write a syntax proposal

<scribe> Closed.

A-13-01: MSM to draft a complete table

<Scribe> Continued. New ETA 27 July 2006.

XProc syntax

Norm: Norm attempts to summarize.

<alexmilowski> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0066.html

Norm: We can talk about input/output bindings today and name/label/from as those seem to be issues we might be able to resolve.

Murray: I'm happy to discuss these things, however, my thought is that the input/output bindings and the naming and cross referencing are two of the trickier things.
... We may need the white board.
... Is there something more fruitful to discuss?
... And whether or when are we going to get the strawman document to a stage where we can begin using it for discussion.

Norm: For the latter question, I'd like to get to that point by next week.

Murray: I'd be ok with saying at the end of the face-to-face. What I want to start discussing soon is changes to a document.

Norm: With respect to the former point, those were the best issues I could come up with, but I'm open to suggestions.

Alex describes message 66. See URI above.

Richard: I agree with the approach, but I don't think you've factored out the naming issue.
... What I would have said is an input binding is a pair of the name of an input declared by the component and a docment flowing through a pipe in a pipeline.
... And an output binding is a pair of a name of an output declared by the component and a document flowing out of the pipe.
... What you've actually said implies that names are the mechanism that will be used. The other possibilities are that you name the pipes, or that there are no names on the outputs, you just refer to them by component and output name.

Alex: I was hoping to come to some agreement before we begin naming.
... Can you grab one of these things in an abstract sense and be able to look at it with some perspective of a syntaxless thing.
... There are aspects of dangling pointers (wrt includes) that may need to be resolved.

Richard: Ok, so there's an asymetry between inputs and outputs. Inputs can't be "here documents" and probably can't be URLs.

Alex describes a case where maybe he did put a URL on an output.

<alexmilowski> The example I was talking about: http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-6.xml

Norm describes how input is sometimes a declaration and sometimes it's a binding.

Richard: I don't think there's any ambiguity that using input/with-input solves.
... That case (use-case-5-6) where one is called url-request and one is reference-to-output, is final-doc-reference.xml the name used in result-document in XSLT?

Alex: Yes

Richard: I find it very confusing that these output elements have from attributes

Alex: I always use name to name the thing that you're providing and from always points to something with a name.

Norm: I agree with Richard, I think it's hugely confusing.

Alex: I don't think we have inputs/outputs nailed down at the conceptual level yet.

Murray: We haven't agreed on the model and we seem to be going all over the place.

Norm: Conceptual differences? I thought we understood them pretty well conceptually.

Alex: Maybe output is the real hard case.

Richard: One way of looking at it is, that you bind inputs to outputs. You don't bind both of them to something.
... It's only inputs that you need to bind to things.

Alex: What about two XSLT steps?

Richard: Dot syntax

Murray: I have a different answer.
... If I have a for-each or a choose, each area within that may or may not have an output.
... Let's say I've got five of them: a, b, c, d, e.
... I can name them each and then try to resolve them in later steps, or I can use Richard's dotted syntax.
... My answer would have been to give an output at a top level.

<alexmilowski> +1 to this...

Some discussion of the the naming case in the context of a choose with when's.

Norm observes that in a choose, you can say that the output of the choose is some label, but if the first when contains three steps, you have to bind the output from one of those steps to the output of the choose.

Discussion of syntax defaulting.

Norm: Let's not worry about the defaulting case until later.
... Do we agree conceptually about inputs and outputs?

Alex: I don't think we're all on the same page about outputs.

Richard: I don't think there's any real disagreement conceptually because I think we all agree that it's conceptually equivalent to a model where you have explicitly named pipes and what inputs nad outputs do is equivalent to attaching things to the end of pipes.
... Setting aside cases where you read it directly from an href or something like that.
... Then the question becomes, do we attach things by giving names to all the ends, or do we have a scheme in which pipes are implicitly named by using some dot syntax as I suggested.
... Or do we have some other syntax where pipes point to components or components point to explicit pipe objects.

Alex: I have to say I was worried about having to name things a lot and while the syntax is up in the air, having to map those names to things I"m going to use in the pipeline isn't a big deal.

Norm: I've convinced myself that the two styles are isomorphic.
... It's going to come down to what syntax is easier.

Richard: I'm worried about what Alex said, I thought that if you referred to another pipeline you never got to see what was inside.

Norm: Indeed.

Alex: It depends on whether you can do textual sorts of inclusoin.

Richard: There's no question that we're going to have to provide names for the things that are parameters to the *pipeline*
... Looking at your example, you've been forced to name things document-2, document-3, etc. Those aren't meaningful names.

Alex: The use cases I wrote have better names.

Murray: It's possible that we can make this taste-good and be less-filling at the same time. If I don't name things, they're named for me, and if I name them, I can use those names.

Richard: I completely agree.

Norm: We could do both, but the world will think better of us in five years if we muster the courage to pick only one.

Richard: You could stay that steps can be named, and outputs can be named, and you can refer to either one.

Norm: Yes.

Richard: Then we might be able to come up with a uniform syntax for naming everything. Things could all be optionally named, you just have to name enough things to be able to refer to the things you want to refer to.

Norm: Yes, we could do that. And maybe it wouldn't be the most evil thing I've done this week.

Richard: This might also help debuggers.

Alex: I'd like feedback on some specific use cases.
... The XInlude one, 5.2.
... Can we "interfere" with the nested XIncludes?
... Also, 5.4.1 and 5.4.2, the aggregation use cases.

Alex: This one has to do with collections.
...Also: 5.6, where XSLT produces two things.

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/07/27 16:01:25 $