See also: IRC log
(08:00+01:00-18:00+01:00 Monday and Tuesday, 27-28 Feb)
Andrew would like to call in.
Alex: Infosets/representation of inputs as a topic for the f2f
Norm: Processing model
Richard: I was speaking about the non-xml stuff being the same thing
Alex: Does it make sense to spend some time talking about the various tools that are out there?
Richard: I was going to suggest the attendees that have a pipeline implementation give a brief presentation on it.
<PGrosso> The above URL is from Alessandro.
<PGrosso> Alex: Point 1 is to have a defn of parameters which we do now.
<PGrosso> Alex: Point 2 should be taken care of now too. Alessandro agrees.
<PGrosso> Alex: Point 3 (standard names for steps). We discussed that a component is like "XSLT" but a step is a thing in the pipeline that may make use of a given component like XSLT.
Richard: Is a step a component plus some parameters plus it's position in the pipeline?
Alex: Yes. In fact a step might even use multiple components.
Richard: We probably don't have to come to complete closure on this now
Alessandro: My comment was
narrower, just that in the particular place in 4.6 where the
word "step" is used, the word "component" would have been
... I see a Step like a function call and a Component more like a function.
Alex: I could change 4.6 to say Component and be happy with that
Alex: Point 4 is intended to say that we won't create a pipeline vocabulary that can't be validated
Richard: Can you give an example of something that couldn't be validated?
Alex: Atom, for example, voilates
the XML Schema UPA rule by allowing interleaving at several
... I would like to avoid that, I'd like to create a vocabulary that can be validated with either language
Richard: I agree as long as it's
not taken to extremes. Don't use things that many validation
tools can't validate. But if we wind up with co-constraints (in
attribute values, for example), it may never the less be the
best way to do that.
... We can't rule out all constraints that can't be checked by an XML Schema validator.
... This sounds more like a design principle
Norm: I agree with Richard.
Alessandro: I was thinking of the XSLT case, where there are good things that can't be validated easily with XML schema. I wouldn't like us to constrian ourselves not to do that.
Murray: On the other hand, we'd
like processing languages to be as easily validated as
possible. We should think long and hard before we let this one
... If we're going to allow something that isn't validatable, we're going to think long and hard about it.
Alex: Point 5 is about naming of
... There's no use case for many of the things in the document so that's a more general problem.
Norm: Can you give an example?
Alex discusses giving pipeline documents URIs
Murray: The mechanism that's missing is do I have a way to reference a pipeline and have it invoked
Richard: Do you mean in general
or in a pipeline?
... Do we want pipelines to be able to refer to one another?
Alex: Consider 4.9 on
composition, you could say use XInclude
... I think naming goes along with composition.
Richard: It's been the case in several specifications that the new language has defined it's own inclusion mechansim. It has always been a hope that XInclude was vailable it wouldn't be necessary. Often, alas, it turns out to be necessary.
Norm: I think the design
principle "reuse existing technologies" covers that case.
... I propose that we leave 4.9 and let naming fall out of our composition mechanism if it does
Richard: We also have the case of supplying the pipeline in the URI so that you can write a URI that means run this pipeline on this document with these parameters.
Norm: I can't tell from 4.10 if that is what was for.
Consensus: delete 4.10
<PGrosso> [Norm's email]
Thank you, Paul
Norm describes his ideas
Alex asks about the syntax
Some discussion of flow and parallelism
Richard: I have some problems
that are simpler than Alex's case.
... The use of a "current" infoset has two implications: straight through processing, everything is one input or output unless it's named; the other is that it implies sequential processing.
... I don't think the sequential processing is an issue. But the first one is more important.
... If we want to have some components like "XML diff" then I don't think we want to have the two inputs be described in entirely different ways.
... Maybe one has to be input1 and the other input2, but we shouldn't have to go deeper than that.
... but using names for the non-XML data, then I think that's an approache to consider.
Richard: that isn't what I had in
... Suppose you have a pipeline that wants to cleanup some insignificant diffs and then run the XML diff component.
... I imagine that you might start this pipeline with two inputs and at some point they get merged.
... At the point of the execution of the step that does the diff, I want that to be just like the case where there's only one
Murray: I'm confused.
Alex: Conceptually, this is two pipes inside a pipe I think.
Some discussion of a shell script case
Richard: I'm assuming that we
have a way to have two things in the pipeline, I want to get
them merged later one
... The way we get two things into the pipeline is by having some upstream thing refer to URIs
Erik: I think it's an
oversimplification to use the shell script analogy for
... There are existing pipeline languages that can already handle this case.
Murray: Where I'm having difficulty is the case where there's more than one stdin
Richard: That's only if we only allow stdin on a process.
Murray: If we allow each step to have stdin/stdout, that step can also have other inputs.
Richard: Unix actually has a whole bunch of file descriptors, 0, 1, 2, and with sufficient hackery, you can actually read from 5 without ever giving it a name.
Alex: We need a white board for this.
Norm asks for concrete examples
Nearly out of time