See also: IRC log
Norm, let's meet next on 13 December isntead
Mohamed gives likely regrets for 13 December
2. Why all these steps?
Norm: I don't really have any sympathy for their position
Some answers: pipelines are easier to understand, streaming is likely to be easier in some cases, ...
Henry: I think it's worth emphasizing that we anticipate that a significant user community will be processing very large inputs through very simple pipeliens and having to pay the cost of an XSLT runtime for this is not very attractive
Norm: What do we say about the fact that we don't guarantee streamabilty
Henry: No, that's a QoI issue.
Norm: Ok, let's start there. Anyone want to add anything else?
Richard: The question about streaming is more specific.
Henry: It's very easy to detect a very small subset that's streamable, but that subset covers a lot of use cases.
Richard: If you want to do some analysis, you can stream up to a point and then build a tree which is less practical for XSLT
3. Parallel executions
Norm: I don't understand the comment.
Henry: I don't understand the
... The classic case is a document styled with a stylesheet generated from the same document. What's the problem?
Richard: I think maybe they just don't understand that we're saying you have to make it work.
Norm: I think we should ask them to clarify.
Richard: The statement in the spec about "the order determined by the connections" might be being taken too strong.
Henry: Something like, "in an order consistent with the connections"...
<scribe> ACTION: Norm to reply [recorded in http://www.w3.org/2007/11/29-xproc-minutes.html#action01]
Agreed: we'll give them unreferencable names
Mohamed: I don't find any context where it would be confusing
Norm: It's not possible on pipelines anymore, it's only on other compound steps
Richard: It's only the defaulted
output ports of subpipelines. The only reason for allowing them
is to save people from making up names in simple, linear
... I think if they want to make reference to names out-of-order then they should have to declare the port.
Mohamed: I'm ok with that. It'll be defaulted on both ends usually.
Henry: I think his message has
... Our discussion at the plenary clarified the issues a lot and moved us forward.
... It would be good to get Alex's input. But we could talk about the last three paragraphs.
Richard: The main point of
Henry's message is that there's a proof that it can be made to
... Henry's description is based on the approach that I'm taking which does several passes.
Norm: I suggest we leave this open for a week to get Alex's input.
Henry: We need to say something about reentrancy as well as circularity
Richard: I don't think the term
reentrant is generally understood to mean what you mean
... It's the diamond pattern: a imports b and c and b and c both import d
Norm: Yeah, the editor will have to figure out how to express that. Poor sod.
Norm: I think they're all LEIRIs and that's all we need to say
Henry: I think we should say that.
Norm: I agree. I'll see if that satisfies Alex.
Norm: There was some pushback on the places where I put names, so I think we probably need to discuss fragids and MIME types again
Ricahrd: I think there's value in having the names independent of the fragid question, it improves error reporting.
<ht> Here's the only place I can find which discusses fragids: http://www.w3.org/XML/XProc/2007/08/09-minutes.html#item05
Henry: If we do this, then we
have to address the question of uniqueness. Do we make these
things unique like their sisters and cousins or not?
... We have a general purpose mechanism for naming bits of XML syntax, it's xml:id.
... I'd like to set this aside from the question of our own XPointer scheme for a moment.
... It feels a little bit like we have a hammer in our hands so everything looks like a nail.
... The most bizarre aspect of this is the fact that there's no discussion of the name attribute in some of those places, like p:declare-step.
... If you give a pipeline library a name attribute, people are going to think you can refer to it by name.
... We don't really expect that to mean anything.
... Users are going to think there's some deep complexity there but there isn't, there's barely any there there.
Richard: You took the names out, Norm, but they still get names like !3
Norm: Yes, but if we undo the fragid decision...
Richard: Like I said, I use the names to report errors and I use the ! names if they don't have any.
Henry: So what's the question?
Richard: Well, there's no doubt
that all steps have to have names because they have
... So it's the things that don't have ports: pipeline-library, catch, when, otherwise, ...
Henry: My compromise position is, I'm a little nervous, but I could live with putting names on the schizophrenic contstructs.
Richard: It's the things inside try and inside choose except group.
Henry: Like I said, I could live
with names there; it doesn't really conflict with the object
... It's declare-step that I think shouldn't have one.
Richard: That's funny, I was going to go the other way. It seems that declare-step should be like pipeline in this regard.
Norm: We do have this weirdness with namespace and name in pipeline library.
Henry: I agree, pipeline and declare-step should have the same naming structure.
Norm: Name doesn't work then because they're NCNames.
Richard: Why would you ever want to have a single pipeline library taht declare steps in separate namespaces?
Norm: Because you aggregated them after you wrote them over time; I don't see how the library should have a bearing on the names.
Richard: Do we allow any steps to be in no namespace.
Norm: Yes, though it's not clear that we meant it to be that way.
<MoZ> no namespace is impossible because of ignorable-prefix
Norm: So where are we?
Henry: I'm prepared to float the following pair of changes:
<MoZ> <foo:step xmlns:foo="">...</foo:step>
Henry: Reinstate optional names on when/otherwise/catch and remove name from pipeline and namespace from pipeline-library
Norm: You can't remove name from pipeline, that's how the steps refer to its ports
Henry: No, they use the local-name of the type attribute
Norm: Uhm. My initial reaction is "eew" but maybe I need to think about it some more.
Henry: Having to write name="foo" type="my:foo" is just hopelessly confusing.
Richard: The reason that pipeline
is like this is because if its usual schizophrenia
... You're allowed to have an unnamed pipeline at the moment.
... And an untyped one.
Scribe lost Richard's thread
Henry: We'll never see names and types that are different
Norm: I don't agree, I might name all my pipelines 'main' irrespective of their type
Henry: So what I said before with a small modification:
1. Remove name from declare-step and pipeline-library
2. Add name to when/otherwise/catch
3. Remove namespace from pipeline-library
4. Remvoe the magic about name/namespace for defaulted types in a pipeline library
5. Make type required on a pipeline in a pipeline library
Norm: So the editor should give that a wack?