XML Processing Model WG

Meeting 93, 29 Nov 2007


See also: IRC log


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


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/11/29-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/11/15-minutes


Next meeting: telcon 6 December 2007?

Norm, let's meet next on 13 December isntead

Mohamed gives likely regrets for 13 December

Comment #68 Comments from the XSL WG

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C068

1. Resolved

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 third sentence.
... 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"...

4. resolved

5. resolved.

6. resolved

<scribe> ACTION: Norm to reply [recorded in http://www.w3.org/2007/11/29-xproc-minutes.html#action01]

Comment #69 should default ports be named

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C069

Agreed: we'll give them unreferencable names

Comment #70 circular imports

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C070

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 pipelines.
... 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 been overtaken.
... 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 work.
... 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 here
... 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.

Comment #71 http-request/etc. and URI encoded references

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C071

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.

Comment #72 name attributes and fragment identifiers

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C072

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 ports.
... 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 model.
... 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?


Any other business?



Summary of Action Items

[NEW] ACTION: Norm to reply [recorded in http://www.w3.org/2007/11/29-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/12/12 19:00:35 $