See also: IRC log
-> http://www.w3.org/XML/XProc/2008/04/10-agenda
Accepted
-> http://www.w3.org/XML/XProc/2008/04/03-minutes
Accepted
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.
<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.
Accepted.
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.
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.
Accepted.
None.
Adjourned.