See also: IRC log
Rui gives regrets for 17 and 24 April.
Alex gives regrets for 17 April.
Norm and Richard summarize.
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.
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.
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?
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.
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?
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
... 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
... 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.