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

XProc Minutes 29 Jan 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 29 Jan 2009 14:12:19 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m21vumsz8s.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/01/29-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 135, 29 Jan 2009


   See also: [3]IRC log


           Norm, Vojtech, Alex, Henry, Mohamed





     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 5 Feb 2009?
         4. [8]Review of Widgets 1.0: Packaging and Configuration
         5. [9]074. Select expression in input declaration
         6. [10]026. New http-request test
         7. [11]036. Multiple inputs/outputs
         8. [12]040. Schematron for XProc validation
         9. [13]045. Using p:variable
        10. [14]051. 2.13 flawed?
        11. [15]068. err:XC0016 and err:XD019
        12. [16]Any other business?

     * [17]Summary of Action Items


  Accept this agenda?

   -> [18]http://www.w3.org/XML/XProc/2009/01/29-agenda


  Accept minutes from the previous meeting?

   -> [19]http://www.w3.org/XML/XProc/2009/01/22-minutes


  Next meeting: telcon 5 Feb 2009?

   No regrets given.

  Review of Widgets 1.0: Packaging and Configuration

   -> [20]http://www.w3.org/TR/2008/WD-widgets-20081222/

   <scribe> ACTION: Mohamed to review the spec and report back if he finds
   any issues [recorded in

  074. Select expression in input declaration

   -> [22]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C074

   Norm summarizes, and reports that his implementation would return <book/>

   Vojtech: I'm more inclined to read the spec to say that the select is
   applied only when the default binding is used.

   Norm: It seems to me that preserving the select expression is the safest

   Vojtech: That makes sense for the default, but it may make no sense if you
   pass in random input.

   Mohamed: I agree with Vojtech.

   <Zakim> ht, you wanted to agree with Vojtech

   Henry: My argument would be that the documentation distinguishes two
   cases, when there's a default and when there isn't. Historically, there
   used to be three different tableaux.
   ... I would hope that the select appears only in the giving a default
   case, and not in the vanilla declaration case.

   Norm: The tableaux in the spec does allow it, but that's because it no
   longer distinguishes between the case where you can provide a default and
   when you don't.

   <ht> More to the point, the following: "If a binding is provided in the
   declaration, then select may be used to select a portion of the input
   identified by the p:empty, p:document, p:data, or p:inline elements in the

   Mohamed: I think the note in 5.1.1 points in the same direction.

   Norm: Proposal: the select on the declaration is only used if the default
   binding is used.


   Mohamed: Can we add that the select cannot be used if there isn't a
   default binding.

   <scribe> ACTION: Norm to clarify when the select applies. [recorded in

  026. New http-request test

   -> [24]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C026

   Norm summarizes the thread.

   Vojtech: Someone on xproc-dev noted that if you allow cookies, then you
   sometimes need to preserve state.

   Norm: I think we should do cookies within a single http-request step, but
   that saving cookies over a longer period should be implementation-defined.
   ... Proposal: By default, http-request should follow redirects and should
   preserve cookies (for the duration of that single request)


   Mohamed: Can we say something about preserving cookies for a longer period
   being implementation defined.

   Proposal: Implementations MAY provide implementation-defined mechanisms to
   preserve cookies for longer periods of time, but are not required to do


   Norm: The next question is p:document, p:load, etc. I think we should say
   that those instructions follow redirects but do not support cookies or
   other advanced user-agent features.

   Henry: I think we have to be explicit about this for interop.

   Mohamed: I think we should keep these instructions simple.

   Vojtech: But at least redirect should be handled.

   Henry: Absolutely. Do what standard libraries do, but nothing else.

   Norm: Proposal: p:document, p:load, etc. follow redirects but do not
   preserve cookies, etc.

   Vojtech: Do we need to say something about steps like p:xsl-formatter?
   ... And other steps that can perhaps store to http URIs?

   Norm: I don't think PUT and POST support redirect...
   ... I think we've left the ability to write output as implementation
   defined for security reasons, so we don't have to say anything.


   Norm: The last question is, do we want to support the ability to *not*
   follow redirects.

   Some discussion about whether or not you need to provide options for all
   these possible features.

   Mohamed: This is related to HEAD right, which doesn't follow redirects.

   Norm: If that's the case, then I'm happy to leave the option out.

   Alex: The spec says that GET and HEAD MAY follow redirects.

   Norm: "May"? That's not useful.

   Alex: There are a whole bunch of variations here.

   Norm: Ok, I've lost all personal interst in persuing this. I don't want to
   add more compexity here. We can add it in 1.1 if the 1/2 of 1% of people
   who might ever care, do in fact care.

   Proposal: No such option.


  036. Multiple inputs/outputs

   -> [25]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C036

   Norm summarizes.

   Norm: Allow source/result to accept sequences by default?

   Mohamed: no.

   Henry: Why?

   Mohamed: Because I think it's and advanced feature and you should have to
   explicitly enable it.

   Vojtech: I'm not sure it's really necessary to restrict sequences.

   Norm: I think the reason may have been because serializing a sequences
   isn't something you can do with vanilla XML

   Vojtech: On p:pipeline you could add your own output port and then you
   have a pipeline with two outputs.

   Norm: I think James point that this will either be an FAQ or we should
   change it.

   Henry: I think, on balance, I'm in favor of making this change because it
   imposes no change on any who's been using the steps but will allow more

   Mohamed: In case you're testing on an error, it'll change.

   Alex: I remember this being that basically p:pipeline was supposed to be
   the simple case.

   Straw poll: Should we change p:pipeline to allow sequences on input and

   Unanimity for no change.

   Proposal: the status quo remains, we'll make no change here.


  040. Schematron for XProc validation

   -> [26]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C040

   Norm summarizes.

   Norm: I'd like to respond, "Yes, it might. And if you write it, we'll put
   it somewhere that the public can see it."

   Mohamed: I agree.

   Proposal: The WG will not undertake this task.


  045. Using p:variable

   -> [27]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C045

   Norm summarizes.

   Mohamed: I think the use case is not that simple. Just saying that you
   want to have the variable on the output doesn't mean you know the
   structure you need.
   ... I think the thread offers several solutions that are sufficient.

   Vojtech: I agree you can, but it is a bit annoying.

   Norm hypothesizes about we might do, but doesn't want to do it.

   Alex: Isn't XSLT sufficient here?

   Norm: I think it is.

   Vojtech: It's not that simple to do, there is a little bit of work

   Mohamed: I think it's worth letting exproc do this.

   Alex: It's not that bad.

   Norm: Does anyone want to argue that we should add a step for this?

   None heard.

   Proposal: No change, leave the status quo.


  051. 2.13 flawed?

   -> [28]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C051

   Norm summarizes.

   Norm: The question, I think, is if we can impose constraints on future
   working groups.

   Henry: I'd be surprised if that caused a problem.
   ... Like all restrictive covenants, it's subject to the will of the court
   at the time when someone does violate the constraint.

   Norm: So the high order bit is, there's no precedent for getting bounced
   because of this point.

   Henry: I think that's right. You can, for example, have a namespace
   document that says "frozen".

   Norm: Proposal: leave the status quo


  068. err:XC0016 and err:XD019

   -> [29]http://www.w3.org/XML/XProc/2008/11/cr-comments/#C068

   Norm thinks this is editorial on furthe reflection and proposes we accept

   Proposal: Accept the change, removing err:XC0016 in favor of err:XD0019.


  Any other business?

   Norm: The W3C Technical Plenary will be held in Santa Clara, CA, US, 2-6
   November, 2009.
   ... I propose that if we're still a chartered WG in 2009, we agree to meet
   there as our next f2f.

   Mohamed: Any word on charters?

   Norm: No, not yet. But I'm not expecting any problems.

   Mohamed: If the US immegration policy will allow Europeans into the

   Norm: Yes, tentatively, that's where we'll plan to meet.


Summary of Action Items

   [NEW] ACTION: Mohamed to review the spec and report back if he finds any
   issues [recorded in
   [NEW] ACTION: Norm to clarify when the select applies. [recorded in

   [End of minutes]


    Minutes formatted by David Booth's [32]scribe.perl version 1.133 ([33]CVS
    $Date: 2009/01/29 19:10:21 $


   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/01/29-agenda
   3. http://www.w3.org/2009/01/29-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#agenda
   5. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item01
   6. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item02
   7. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item03
   8. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item04
   9. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item05
  10. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item06
  11. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item07
  12. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item08
  13. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item09
  14. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item10
  15. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item11
  16. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#item12
  17. http://www.w3.org/XML/XProc/2009/01/29-minutes.html#ActionSummary
  18. http://www.w3.org/XML/XProc/2009/01/29-agenda
  19. http://www.w3.org/XML/XProc/2009/01/22-minutes
  20. http://www.w3.org/TR/2008/WD-widgets-20081222/
  21. http://www.w3.org/2009/01/29-xproc-minutes.html#action01
  22. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C074
  23. http://www.w3.org/2009/01/29-xproc-minutes.html#action02
  24. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C026
  25. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C036
  26. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C040
  27. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C045
  28. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C051
  29. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C068
  30. http://www.w3.org/2009/01/29-xproc-minutes.html#action01
  31. http://www.w3.org/2009/01/29-xproc-minutes.html#action02
  32. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  33. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 29 January 2009 19:13:02 UTC

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