- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 10 Apr 2008 12:02:02 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2r6ddy9z9.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/04/10-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 107, 10 Apr 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Paul, Vojtech, Norm, Rui, Henry, Alex, Richard, Andrew, Michael
Regrets
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 17 April 2008?
4. Adjusting base URIs
5. Error ports
6. Pipeline names/types
7. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2008/04/10-agenda
Accepted
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2008/04/03-minutes
Accepted
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[7]
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.
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.
Accepted.
Any other business?
None.
Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2008/04/10-agenda
[3] http://www.w3.org/2008/04/10-xproc-irc
[7] http://www.w3.org/TR/xquery-operators/#func-base-uri
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[10] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[9] version 1.133 (CVS
log[10])
$Date: 2008/04/10 16:01:10 $
Received on Thursday, 10 April 2008 16:02:39 UTC