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

XProc Minutes 2 July 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 08 Jul 2009 11:54:34 -0700
To: public-xml-processing-model-wg@w3.org
Message-ID: <m27hyj0zv9.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/07/02-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 148, 07 Jul 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Paul, Vojtech, Henry

   Regrets
           Mohamed

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 9 July 2009
         4. [8]Next meeting: 16 July 2009
         5. [9]Implicit outputs on p:pipeline/p:declare-step
         6. [10]Escaping in p:escape-markup
         7. [11]137 Default value for omit-xml-declaration
         8. [12]Add encoding to p:data
         9. [13]Any other business

     * [14]Summary of Action Items

   --------------------------------------------------------------------------

  Accept this agenda?

   -> [15]http://www.w3.org/XML/XProc/2009/07/02-agenda

   Accepted

  Accept minutes from the previous meeting?

   -> [16]http://www.w3.org/XML/XProc/2009/06/18-minutes

   Accepted

  Next meeting: telcon 9 July 2009

   Unlikely to achieve quorum; cancelled.

  Next meeting: 16 July 2009

   Accepted

  Implicit outputs on p:pipeline/p:declare-step

   Norm summarizes.

   Norm: Actually, it doesn't apply to p:pipeline.

   Vojtech: I don't like a default output port on p:declare-step because it's
   anonymous. But Henry suggested that we call it "result" and I think maybe
   that's ok.

   Henry: I appreciate that the situation is complicated; but it seems like
   it catches the 80/20.

   Vojtech: One thing I find weird. Suppose you have a declare-step in a
   library that has an implicit output; then you can't refer to it by name

   Norm: That's fixed if we say the name is "result"

   Vojtech: We say similar things about viewport.
   ... So it's not such a big deal. Saying the rule doesn't apply to
   p:declare-step is maybe a bigger change.

   Norm: I can see advantage of keep the rule and naming it result.
   ... but then that's inconsistent unless we always say that the implicit
   output is named "result".

   Henry: It's hard to guess which inconsistency is least likely to bite
   people.
   ... The inconsistency that I rejected is maybe not so bad.
   ... If what we're saying is that either you get full scale defaulting or
   you get none.
   ... If you need, for good reasons to change it from pipeline to declare
   step, you're going to have to declare an input port so you might as well
   declare an output port at the same time.
   ... So we could say there's no defaulting on the way in or the way out.

   1. We special case p:declare-step so that the implicit output port rule
   doesn't apply.

   2. We don't do that, and then we have odd issues with ths anonymous port
   name

   3. If we fix the odd issues by giving the port a name, then it's different
   because the other implicitly created ports don't have that name

   4. We can fix that point by making the name always "result" in all cases.

   Norm: My concern about 4 is that it can lead to less readable pipelines.
   Because users willb e able to refer to ports by name that are not
   explicitly named anywhere.

   Henry: I'd be happier to go with 1 if we make at least some of our library
   examples use p:pipeline.
   ... We don't have any library examples, so I'm inclined toward 1.

   Vojtech: It's my second favorite, but I can accept it.
   ... I don't like anonymous outputs, but maybe that's a personal issue.

   Henry: Maybe we should put this in countdown for a week.

   Norm: Ok, I'll highlight this tentative decision and give folks two weeks
   to push back.

  Escaping in p:escape-markup

   Norm: This is CR#135.

   Norm summarizes.

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

   Norm: We could change the spec to say what is escaped, but I think that
   would be a bit weird.
   ... Anyone want to argue for a change here?

   Paul: Let's stay away.

   Henry: What does serialization say?

   Norm: Oh, right. This isn't about unescape markup at all. All unescape
   markup does is turn those characters into literal characters in the data
   model.
   ... This is all about serialization.

   Henry: Serialization says that characters that must be escaped...must be
   escaped.
   ... Nothing else seems relevant. I don't think we need to say anything.
   ... Adding more requirements would be obnoxious.

   Proposed: Close without action.

   Accepted.

  137 Default value for omit-xml-declaration

   Vojtech: I brought it up, but I don't think we need to do anything about
   it.

   Henry: I've found, in general,that I'm more often irritated when I get it
   and didn't want it than vice versa.

   Vojtech: I'm ok.

   Proposal: Close without action.

   Accepted.

  Add encoding to p:data

   Norm summarizes.

   Vojtech: The way it is in the spec now, there are two or three
   possibilities about how the XQuery step handles the input.
   ... It's all based on the content-type information.

   Norm: Ok, the question of whether or not p:xquery is ever allowed to
   base64 decode a chunk of data is open, but I still don't see a downside to
   adding the encoding information to the output of p:data

   Vojtech: And we could say that steps are allowed to decode it

   Norm: I'm not as sure about that anymore

   Vojtech: It seems to be just XQuery

   Norm: I'm willing to add that rule to XQuery; XQuery already has a weird
   bunch of rules.

   Proposal: Add [c:]encoding to the output of p:data.

   Accepted.

   Proposal: Add a new rule to the p:xquery step that says it can base64
   decode c:data content
   ... if it's encoded.

   <scribe> ACTION: Norm to proposal the exact text of the new rule for
   p:xquery that can base64 decode [recorded in
   [18]http://www.w3.org/2009/07/02-xproc-minutes.html#action01]

   We'll come back to this in two weeks as well.

  Any other business

   None heard.

   Adjourned; talk to you all in two weeks.

Summary of Action Items

   [NEW] ACTION: Norm to proposal the exact text of the new rule for p:xquery
   that can base64 decode [recorded in
   [19]http://www.w3.org/2009/07/02-xproc-minutes.html#action01]

   [End of minutes]

   --------------------------------------------------------------------------

    Minutes formatted by David Booth's [20]scribe.perl version 1.135 ([21]CVS
    log)
    $Date: 2009/07/08 18:53:22 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/07/02-agenda
   3. http://www.w3.org/2009/07/02-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/07/02-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/07/02-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/07/02-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/07/02-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/07/02-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/07/02-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/07/02-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/07/02-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/07/02-minutes#item08
  13. http://www.w3.org/XML/XProc/2009/07/02-minutes#item09
  14. http://www.w3.org/XML/XProc/2009/07/02-minutes#ActionSummary
  15. http://www.w3.org/XML/XProc/2009/07/02-agenda
  16. http://www.w3.org/XML/XProc/2009/06/18-minutes
  17. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  18. http://www.w3.org/2009/07/02-xproc-minutes.html#action01
  19. http://www.w3.org/2009/07/02-xproc-minutes.html#action01
  20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  21. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 8 July 2009 18:55:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 July 2009 18:55:27 GMT