XML Processing Model WG

Meeting 107, 10 Apr 2008


See also: IRC log


Paul, Vojtech, Norm, Rui, Henry, Alex, Richard, Andrew, Michael


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/04/10-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/04/03-minutes


Next meeting: telcon 17 April 2008?

Rui gives regrets for 17 and 24 April.

Alex gives regrets for 17 April.

Adjusting base URIs

Norm and Richard summarize.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0018.html

Richard: we need to say what the base URI of an empty document node is.
... And we need to say what happens if a document in the pipeline has no base URI.
... I also suggested a relativize function, but it turns out to be less useful, I think.

Alex: Is there anything different from the XPath 2.0 functions?

Richard: No, but they'll be available to XPath 1.0 processors if we put them in our namespace.

Norm: I think we want to make sure that XPath 1.0 implementations can do these things.

Alex: I think this is a slippery slope.

Richard: If we don't put this in, XPath 1.0 impls will have to indepently invent this. This way, they have a uniform name and will be interoperable.
... Especially if we want to add some sort of relativize function.

Alex: I think if we do this, we must make it exactly the same as the XPath 2.0 functions.

<richard> http://www.w3.org/TR/xquery-operators/#func-base-uri

Some discussion of whether we have to invent our own errors or return the XPath 2.0 errors.

Norm: I'd be content to say that they return the F&O error codes.
... I could go the other way as well.

The editor can decide when he's writing it up.

Proposed: Add p:base-uri() and p:resolve-uri() as spec'd by Richard, to be the same as the XPath 2.0 functions.


Error ports

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0010.html

Vojtech summarizes.

Norm: The catch step can read from an error port, so I think it follows that there must be ports that connect to it. Even if the user can't read it.

Some discussion of the motivation.

Norm: Anyone have any thoughts on what we might do or say differently?

Richard: I haven't looked in a while, there isn't any concept that a subpipeline aggregates the error ports of its steps or anything like that is there?

Norm: No.

Vojtech: I found this sentence most confusing "All steps have an implicit output port for reporting errors that must not be declared."

Norm: Well, why don't we ask the editor to try to make this a little clearer.

Richard: Minor point: sometimes we call the "error ports" and sometimes "error output ports". It would be good to make them consistent.

Pipeline names/types

Norm summarizes.

Richard/Henry: Why can't the type be in no namespace?

Norm: Well, because it helps prevent name collisions if you import them.

Vojtech: The purpose of type is for importing, right?

Richard: Yes.

Vojtech: Removing the name is a bit strange, because you have to use this type. Everywhere else you use 'name'. I think that's a bit strange.
... We could have both.
... That's what I'd like: bring back the name.

Henry: We thought it was confusing to have both name and type.

Vojtech: You only need type for import.

Richard: It used to be the other way around, if you had a name but not a type, the type got constructed.
... I agree it's dual purpose is a bit odd.

Norm: We used to have all sorts of magic, but now that we've removed that, I think maybe the simplest thing would be to put back both name and type.

Richard: We could have some magic syntax like "step='*'" to refer to the pipeline.

Norm: Er, yeah, well.

Richard: The name you invent isn't visible anywhere else, so that seems a bit odd.

More discussion about leaving 'step=' off.

What are the options:

1. The status quo

2. Leaving 'step=' out makes the pipe refer to the ancestor pipeline.

3. Use '*' as the name of the ancestor pipeline

4. We could have both name and type attributes, functioning independently

Vojtech: If we put the name attribute on the pipeline, then it would also have to be on declare step.

Some discussion of the consequences of putting a name attribute on p:pipeline and p:declare-step. Consensus appears to be that it won't be an issue as neither pipeline nor declare-step are actually “steps” in the subpipeline sense.

Richard: I think the names on declare-step and pipeline shouldn't go in the surrounding environment.

Norm: We could add that rule.
... I don't think we have the idea that some steps are not steps.

Henry: Sure we do. None of variable, pipelinfo, or documentation are steps.

Straw poll: which do you prefer, 1-4.

Results: five for choice 4 and two for choice 2

Propose: we adopt choice 4.


Any other business?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/17 16:54:03 $