W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2007

XProc Minutes 9 Aug 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 09 Aug 2007 12:18:58 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87tzr8hea5.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/09-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 78, 9 Aug 2007


   See also: IRC log[3]


           Alessandro, Mohamed, Andrew, Norm, Alex, Richard

           Paul, Henry, Michael




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 16 August 2007
         4. Comments on the new draft
         5. Question of MIME type/fragid
         6. Question about anonymous steps or defaulted names.
         7. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/08/09-agenda

   Reorder items 2 and 3

   Mohamed: I'd like to talk about p:pack.

   Norm: Ok, we'll make that item 5

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/08/02-minutes


  Next meeting: telcon 16 August 2007

   Probably regrets from Mohamed

  Comments on the new draft

   -> http://www.w3.org/XML/XProc/docs/langspec.html

   Norm: I think it's pretty good except for the namespace bindings.

   Richard: The diffs are pretty amusing.

   Mohamed: What happend to err:?

   Norm: I took it out for err:errors and err:error because we can use c: for
   ... Then I remembered error QNames, so I put it back.
   ... Everyone ok with that?

   Seems so.

  Question of MIME type/fragid


   Norm: Are we going to define one and do we want one?
   ... Having a MIME type lets us identify pipeline documents; having a
   fragid syntax would let us describe how to point to important parts of a

   Norm describes his attempt at a fragid syntax.

   Richard: We need to get this right before Last Call, right?

   Norm: Yeah, I guess so.

   Alex: Do we need to have a fragid syntax?

   Murray: What would we identify

   Norm: We would identify steps, ports, and options.
   ... We don't have a need, it's a question of whether we want to provide
   hooks for others.

   Murray: I'm some author outside a group of pipelines; so I might write an
   RDF statement that talks about these things; I might create a hypertext
   link to one.
   ... Can I invoke a step this way?

   Norm: No
   ... You could also use it for error messages.

   Richard: Seems strange to do this when we don't use them.

   Norm: I get the impression that we're leaning towards a MIME type but not
   the fragment identifier.

   <richard> the xpath xpointer scheme doesnt exist

   Murray: I can see the value in being able to refer to steps from the
   outside. I'm not sure I get the value in having fragids for the ports.

   Norm: So I propose that we define a MIME type, application/xml+xproc, but
   not a fragment identifier syntax.

   Murray: How hard is it to point to steps?

   Norm: Easy, if they have names and the names are unique.

   Richard points out that pipelines in a library could easily have steps
   with the same names

   Alex: There's not a lot of precedent here, lots of recent specs don't have
   MIME types.

   Richard: I haven't heard any compelling arguments for a fragid syntax.

   Norm: So it seems like the consensus is MIME type yes, fragids no.

   <MoZ> <p:documentation xml:id="foo" />

   Murray: If we think pipelines are going to be popular, which I think we
   do, it seems like there will be lots of people who want to talk about

   Alex: One rational position is to not require to sprinkle xml:id over
   their documents. If you want to point to something, you have to name it.
   ... Then we can do something like what Norm proposed and provide a
   mechanism for pointing to them.

   Richard: Though I see that you might want to talk about these things,
   without tools, it's not terribly useful to point to them.

   Murray: That's a chicken and egg thing, isn't it?

   Norm: I'd like to set this aside for a moment and go on to the next item.

  Question about anonymous steps or defaulted names.


   Norm outlines his message

   Murray: I like the idea.

   Mohamed: I'm not sure I like the defaulting of inputs to the p:pipeline.

   Norm: Yeah, but that's not really the issue here.

   Alex muses about the syntax Norm proposed.

   Richard: The presence of named ports wouldn't changed the names, would it?

   Norm: We could actually use "source" and "result" for manufactured port

   <alexmilowski> xyzzy-nn

   Murray: Would we have to use the section symbol in the URI?

   <MoZ> <p:pipeline>

   <MoZ> <p:for-each>

   <MoZ> <p:xinclude/>

   <MoZ> </p:for-each>

   Norm: Yes, that's the price you pay for not having put your own name on
   the step.

   <MoZ> <p:for-each>

   <MoZ> <p:xinclude/>

   <MoZ> </p:for-each>

   <MoZ> </p:pipeline>

   Norm: Is anyone in principle against this proposal?

   Mohamed: Yes.

   Norm: Why?

   Mohamed: It's giving more possibilities for users to not use names.

   <alexmilowski> mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

   Alex: It'd be nice if we picked a character name that doesn't require URI

   Norm: Ok, how about "!"

   Mohamed: I'm ok with naming steps.

   Norm: One of the goals is to remove a concept from the spec, I don't
   anything to be anonymous.

   Richard: You think you're going to use these in some hypothetical fragment

   Alex: I like the idea that you can't use the manufactured name in the

   Richard: We're going to specify that the things have these names. Are
   implementations going to have to use them?

   Norm: In a running pipeline, you'll never see them.

   Richard: So this has no normative effect.

   Norm: True, but the spec will still be simpler because it has one less

   <alexmilowski> +1

   Norm: I propose that we direct the editor to give this a try and see if we
   like it.


   Norm: Drat. We won't get through namespaces in 10 minutes, let's return to
   MIME type/fragid.

   Alex: I'm all for using the manufactured names in a fragid syntax.

   Norm: Anyone opposed to having a fragid syntax for steps.
   ... I propose we direct the editor to give that a whack too.


   Mohamed: Take care that we don't overlap with the use of xml:id.

   Norm describes the problem

   Alex: Have you looked at what XSLT does with xsl:element

   Norm: Yes, but that doesn't work for us.

   Richard: Suppose you just construct arbitrary strings in options, you
   expect those to go through.

   Norm: Then you need the union of all the bindings on all the variables

   Alex: What about the opposite case, where you don't want the bindings from
   the document?
   ... XSLT avoided all this magic

   Norm: So the proposal is, the namespace bindings you get on the match
   option passed to the delete step are the ones that are in scope for that
   p:option. If they don't match up, you lose.

   Richard: XSLT gives you a workaround for these cases.

   Some discussion of the options

   Alex: We could give another attribute on p:delete that could point to an
   element on which to find the namespace bindings for this expression.

   Richard: There'd be security considerations here, yes?

   Alex: I still think "you lose" is the simplest answer.

   Norm: Would anyone be uncomfortable wit the "you lose" proposal?

   None heard

  Any other business?



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/08/09-agenda
   [3] http://www.w3.org/2007/08/09-xproc-irc
   [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.128 (CVS
    $Date: 2007/08/09 16:16:48 $

Received on Thursday, 9 August 2007 16:19:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC