XProc Minutes 10 April 2008

See http://www.w3.org/XML/XProc/2008/04/10-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 107, 10 Apr 2008


   See also: IRC log[3]


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





     * 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


  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.


   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.


  Error ports


   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

   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

   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

   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

   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]


   [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
    $Date: 2008/04/10 16:01:10 $

Received on Thursday, 10 April 2008 16:02:39 UTC