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

XProc Minutes 2 August 2007

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 78, 2 Aug 2007


   See also: IRC log[3]


           Paul, Mohamed, Norm, Alessandro, Richard, Michael





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 9 August 2007
         4. Question about position/size in loops
         5. Proposal to add p:directory-list
         6. Proposal to default step and port
         7. Proposal to add p:generate-simple-document and p:set-attribute.
         8. Proposal to add p:pack
         9. Any other business?
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/07/26-minutes

   Norm thanks Paul for chairing.

  Next meeting: telcon 9 August 2007

   Michael gives regrets

  Question about position/size in loops


   Norm explains his confusion.

   Richard agrees it seems confusing.

   Norm: I propose that we add an extension function for iteration-size in
   for-each and viewport.
   ... Simultaneously, I'd like to suggest renaming them to
   iteration-position and iteration-size.

   <alexmilowski> +1 to that


  Proposal to add p:directory-list


   Norm wonders if his revised proposal addresses the concerns raised last

   Alex: I had security concerns.

   Norm: I attempted to address that by saying the step could raise a dynamic

   Alex: I also wanted the results to be given as a URI relative to the base
   ... What I want is to be able to pass the output of this to XSLT and be
   able to take the href and the right thing will happen.

   Norm: I made the paths absolute so it wouldn't be an issue.

   Alex explains how he wants relative URIs to some base.

   Norm expresses concerns about the user having to construct the absolute

   <p:document href="/foo/bar/baz"/>

   <p:load href="/foo/bar/baz"/>

   Some further discussion about file: as the default.

   <MoZ> <p:directory-list name="list" path="." filter="*.xml"/>

   <MoZ> <p:for-each>

   <MoZ> <p:iteration-source select="//c:file"/>

   <MoZ> <p:output port="result"/>

   <MoZ> <p:load href="{/c:file/@name}"/>

   <MoZ> </p:for-each>

   Norm concedes that he's wrong.

   We don't have AVTs, MoZ!

   <MoZ> <p:directory-list name="list" path="." filter="*.xml"/>

   <MoZ> <p:for-each>

   <MoZ> <p:iteration-source select="//c:file"/>

   <MoZ> <p:output port="result"/>

   <MoZ> <p:load>

   <MoZ> <p:option name="href" select="/c:file/@name"/>

   <MoZ> </p:load>

   <MoZ> </p:for-each>

   Richard: I think we should try to make this work in as many environments
   as possible.
   ... It follows that p:directory-list might not return file: URIs. So it
   should always put the file: on the front.

   Norm: Let's consider the proposal as amended to say that the path names
   are absolute URIs. Usually file: but not necessarily.

   Richard: I can imagine both absolute and relative URIs being useful.

   Norm: I propose then that c:directory set xml:base and provide both path
   and filename. One absolute, one relative.

   Mohamed asks about the absoluteize step.

   Norm agrees we could do that.

   Richard: I propose that the 'path' attribute be spelled 'uri'.
   ... And for the recursive case?

   Norm: I don't know what to do about symbolic links.

   Richard: I don't think we should do anything about symbolic links.

   Norm: So you want to treat them as files, not directories.

   Richard: I think this thing should not follow any symbolic links.

   Norm: I'm perfectly happy to say that what happens if you have a loop in
   the directory structure is implementation-dependent.

   More discussion of symbolic links

   Richard: Perhaps we should have an "other" element that identifies things
   that are neither files nor directories, with some sort of a detail
   ... Do we have a use case for the recursive version?

   Norm: We could leave the recursive option out for V1. Wouldn't bother me.

   Mohamed: Can we change the semantics, maybe we don't need a recursive
   option; just something that can go to any number of levels.

   Norm: We could have a 'depth' option instead of a 'recursive' option.

   Alex: We decided not to support prev/next in Atom in V1, I think we should
   drop recursion, it's very similar.

   Norm: Yes, I agree. So let's leave recursion and depth out for at least
   the first draft in which this appears and see what users say.

   Richard: I'd be happy with that. There's still the possibility of file
   systems having things aren't either files or directories.

   Norm: I suggest we allow c:other and let implementors use extension
   attributes to specify what it is.

   <scribe> ACTION: Alex to write up p:directory-list for the next draft.
   [recorded in http://www.w3.org/2007/08/02-xproc-minutes.html#action01[8]]

  Proposal to default step and port


   Norm: I don't think there's much more to be said beyond what I wrote in
   the email.

   Alessandro: I don't feel strongly, but I think we should limit the number
   of syntactic shortcuts we provide.

   <alexmilowski> I'm ok with this proposal.

   Mohamed: I think this one is valuable because it means you don't have to
   name some steps.
   ... But I think we need to make sure there are no ambiguous cases.

   Norm: I don't think there are any ambiguities.

   Richard: I think we shouldn't bother, I think there are only a small
   number of cases where it would be useful.

   Norm: I detect consensus to not add this feature.

   Resolved: No change, we will not adopt this feature.

  Proposal to add p:generate-simple-document and p:set-attribute.


   Mohamed: A lot of components that we have take as inputs documents.

   (All of them, no?)

   Mohamed: Consider insert which inserts a whole document. But we can't
   construct a document from an option.
   ... I think we need an easy way to construct a document from an option or

   Alex: Can't you use a parameter and select the value of the option.

   Mohamed: Yes, you can go that way, but you can't go the other way.

   Alex: I can set a parameter from an option value; and then I can use the
   p:parameters step to output that as a document.

   Norm: Hey, that's right. p:generate-simple-document is a funky alias for

   Alex: To add attribute, I'd need two steps: I'd have to take the option,
   put it into a parameter, then run it through XSLT to generate the right
   kind of document for p:set-attributes.

   Richard: How much of this can easily be done with XSLT and literal

   Alex: I think generate-simple-document is easy, but add-attribute would
   require a couple of steps.

   Norm: add-attribute does seem like a natural parallel to set-attributes

   Some discussion of how they differ

   Alex: Set-attributes takes all its options from documents; add-attribute
   would take it directly as parameters.

   Norm: So add-attribute is just a shortcut for the
   parameter/xslt/set-attribute combination.

   Richard: if the only distinction is where the values come from, I don't
   like the names.

   Mohamed: Where are we going to stop inventing atomic components?
   ... I found lots of use cases where I needed to add or change an
   attribute, but not many use cases where I needed to set whole groups.

   Norm: We're going to stop when we have consensus to stop.
   ... We don't have any hard-and-fast rules.

   Alex: The set-attributes use cases is the streaming navigation use case
   from our Use Case/Requirements document.

   Norm: The fact that add-attribute can only set one attribute is what
   bothers me.

   Richard: I think it's quite common. I am concerned about adding random
   functions as we think of them; it would be nice if we could have a more
   principled approach.

   Yes, implementors can certainly do it.

   Richard: I think we'll get more input when we get to last call.

   Alex: I'm inclined to wait and see if users find set-attributes too heavy.

   Straw poll: Add p:add-attribute or not.

   Seven "Yes" votes and "1" absention.

   <scribe> ACTION: Alex to add p:add-attribute. [recorded in

  Proposal to add p:pack


   Mohamed explains the idea behind p:pack


   Richard: This takes a number of ports, each of which has a sequence on it.

   Norm: Ouch; we don't have port="*" anymore

   Mohamed: I think it would be ok if the step could just take two sequences.

   Norm: If you only have two of them, you can do it with p:for-each.

   Norm notices that we've run out of time. I suggest we discuss this in
   email and return to it next week.

  Any other business?


Summary of Action Items

   [NEW] ACTION: Alex to add p:add-attribute. [recorded in
   [NEW] ACTION: Alex to write up p:directory-list for the next draft.
   [recorded in http://www.w3.org/2007/08/02-xproc-minutes.html#action01[15]]
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/08/02-agenda
   [3] http://www.w3.org/2007/08/02-xproc-irc
   [8] http://www.w3.org/2007/08/02-xproc-minutes.html#action01
   [11] http://www.w3.org/2007/08/02-xproc-minutes.html#action02
   [14] http://www.w3.org/2007/08/02-xproc-minutes.html#action02
   [15] http://www.w3.org/2007/08/02-xproc-minutes.html#action01
   [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [17] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[16] version 1.128 (CVS
    $Date: 2007/08/02 16:23:58 $

Received on Thursday, 2 August 2007 16:24:38 UTC

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