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

XProc Minutes 11 Dec 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 11 Dec 2008 12:13:36 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2oczi4ou7.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/12/11-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

11 Dec 2008

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Paul, Mohamed, Vojtech, Andrew, Richard

   Regrets
           Henry

   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 18 Dec 2008?
         4. [8]Meeting dates for the rest of December.
         5. [9]Review of comments received so far on our CR
         6. [10]024: Objection to XProc (p:with-option/p:with-param)
         7. [11]UUID/Hash/form-encode
         8. [12]016: How does www-form-urlencode/decode deal with parameters
            in a namespace?
         9. [13]020: p:www-form-urldecode clarifications
        10. [14]027: http-request, redirection, and cookies
        11. [15]Any other business?

     * [16]Summary of Action Items

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

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

   -> [18]http://www.w3.org/XML/XProc/2008/11/20-minutes

   Accepted.

  Next meeting: telcon 18 Dec 2008?

   No regrets given.

  Meeting dates for the rest of December.

   Skip 25 Dec and 1 Jan; next meeting 8 Jan.

  Review of comments received so far on our CR

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

  024: Objection to XProc (p:with-option/p:with-param)

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

   Norm attempts to summarize the thread

   Richard: Presumably a sufficiently clever processor can look at the
   expression and work out if it needs it or not.

   Norm summarizes his position.

   Vojtech: If we change to make p:empty the default, then the no context
   error is ok, but that you'd have to name the steps and make an explicit
   pipe into the option binding is the major argument against this change.
   ... David made a good point in saying that in the majority of XPath
   expressions don't use the context.
   ... I think that's sort of right.

   Norm: In most cases where you don't need the document, you can probably
   use the shortcut syntax.
   ... In cases where you can't use the shortcut syntax, the question is
   which is more common, expressions that do or don't need the context.

   Vojtech: We could make it more explicit in the spec.

   Mohamed: When we don't need any context, we can use the shortcut syntax.
   When you need the context, we can say that you need it for two different
   reasons.
   ... One is to evaluate variables and the other is to evaluate nodes from
   the document.
   ... What we can say is that the context of the shortcut syntax is allowed
   to reference variables but not the context.

   Norm: In the shortcut syntax, you only get literal values, you don't get
   any variables at all.

   Mohamed: I'm ok with the status quo.
   ... I don't think making the proposed change is a good option.

   Richard: Is there anywhere else where there is a port that doesn't get
   bound to the default readable port by defalt?

   Norm: No, I don't think so.

   Richard: So this would be an odd inconsistency: a place where the default
   for the binding is not the same as the default everywhere else.

   Vojtech: What about parameter input ports?

   Norm: Yeah, the binding rules for parameter input ports are a little
   different.
   ... Anyone need further discussion to work out what they think the right
   thing to do is?

   None heard.

   Norm: Is there anyone on the call that supports changing the status quo?

   None heard.

   <scribe> ACTION: Norm to reply to the commenter on behalf of the working
   group. [recorded in
   [21]http://www.w3.org/2008/12/11-xproc-minutes.html#action01]

  UUID/Hash/form-encode

   Comments 015, 019

   Vojtech: Does UUID generate one uuid, or one for each replacement?

   Norm: It generates one and uses it everywhere.

   Vojtech: Then the question is, should these be XPath extension functions
   or steps?

   Norm: And you also asked if they should just return a c:result with the
   value.

   Vojtech: Yes. I think it would be much more useful if it did, because you
   usually want to use it to construct a full URL.

   Norm: Yes, perhaps that would have been better...

   Mohamed: I made a proposal like this on 24 April.

   <MoZ>
   [22]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0065.html

   <MoZ> [23]http://www.w3.org/XML/XProc/2008/05/01-minutes

   Vojtech: The main problem I have with this is that it's sort of two
   string-replace steps, so it's innefficient.

   Norm: Yep.

   Vojtech: It seems very strange.

   Norm: Yes, it's strange. We probably ought to have done it the way you
   suggest. But is it worth going back to Last Call?

   Paul: If it's a change we really want to make, I think we should see if we
   can do it without going back to Last Call.

   Vojtech: You can simulate what I was proposing by using your own empty
   c:result as the input.

   Norm: So, worst case, if we don't change anything, we've got something
   that's a little odd but not actively harmful.
   ... Let's sse if we can summarize where we are. We might like to change
   the way p:uuid, p:hash, and p:www-form-url-encode
   ... so that they simply return a c:result with the result, instead of
   behaving like string-replace. However, you can simulate
   ... that behavior yourself by using a c:result as the input. So there's no
   critical difference in functionality, it's mostly a question of
   aesthetics.

   Norm: I propose that we leave the status quo, but try not to repeat this
   error in the future

   Accepted.

  016: How does www-form-urlencode/decode deal with parameters in a namespace?

   First question, how does www-form-urldecode deal with parameter names that
   contain colons?

   Vojtech: I don't think the spec says anything about that.
   ... We can define a dynamic error.

   Norm: Or we could translate the ":" into some other character like "_"

   Vojtech: I'm reluctant to try to make some possibly complex rules for
   translations.

   Norm: Anyone think it's a bad idea to make it a dynamic error?

   No one says so.

   Norm: We can say that for urldecode, if the resulting name is not a valid
   NCName, that's an error.

   Everone seems happy with that.

   Norm: Then what do we do for encoding, we could just use the localname.

   Voytech: Then you may end up with duplicatews

   Norm: Yep, that's true.

   Vojtech: Sometimes you don't have a prefix at all, so you'd have to
   manufacture them.

   Norm: Presumably that completely defeats the purpose 99% of the time.
   ... Any other proposals besides just using the localname?

   None heard.

   Vojtech: In most cases when you want to use form-urlencode, it's to create
   simple request strings. If you want ot encode parameters in a namesapce
   with prefixes, then you're doing something weird.

   Norm: Right. You can't use these convenience steps if you're operating
   outside their range.
   ... So, go with the localname?
   ... Any objections?

   None heard.

   Accepted.

  020: p:www-form-urldecode clarifications

   Vojtech: It says if any parameter name occurs more than once, the result
   will contain more than one c:param, but it doesn't say what order they
   occur in.

   Norm: Right.
   ... Proposal: the document order of the c:params will correspond to the
   occurrence of parameters reading the input string from left to right.

   Accepted.

  027: http-request, redirection, and cookies

   Norm summarizes the issue

   Some discussion.

   Norm: So what I'm hearing is, we expect p:http-request to follow
   redirections, handle cookies, etc., as described in the HTTP and related
   specs, but the behavior of p:document and friends is implementation
   defined with respect to this behavior.

   Mohamed: We can follow XSLT and Schema that don't say anything about that.

   Richard: Doesn't anyone follow redirections? It doesn't seem reasonable to
   not follow redirecgts.

   Norm: Ok, maybe it's just cookies.

   <scribe> ACTION: Norm to investigate what the features in question
   actually are. [recorded in
   [24]http://www.w3.org/2008/12/11-xproc-minutes.html#action02]

  Any other business?

   None heard.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Norm to investigate what the features in question actually
   are. [recorded in
   [25]http://www.w3.org/2008/12/11-xproc-minutes.html#action02]
   [NEW] ACTION: Norm to reply to the commenter on behalf of the working
   group. [recorded in
   [26]http://www.w3.org/2008/12/11-xproc-minutes.html#action01]

   [End of minutes]

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

    Minutes formatted by David Booth's [27]scribe.perl version 1.133 ([28]CVS
    log)
    $Date: 2008/12/11 17:12:45 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2008/12/11-agenda
   3. http://www.w3.org/2008/12/11-xproc-irc
   4. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#agenda
   5. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item01
   6. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item02
   7. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item03
   8. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item04
   9. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item05
  10. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item06
  11. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item07
  12. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item08
  13. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item09
  14. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item10
  15. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#item11
  16. file:///projects/w3c/WWW/XML/XProc/2008/12/11-minutes.html#ActionSummary
  17. http://www.w3.org/XML/XProc/2008/12/11-agenda
  18. http://www.w3.org/XML/XProc/2008/11/20-minutes
  19. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  20. http://www.w3.org/XML/XProc/2008/11/cr-comments/#C024
  21. http://www.w3.org/2008/12/11-xproc-minutes.html#action01
  22. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0065.html
  23. http://www.w3.org/XML/XProc/2008/05/01-minutes
  24. http://www.w3.org/2008/12/11-xproc-minutes.html#action02
  25. http://www.w3.org/2008/12/11-xproc-minutes.html#action02
  26. http://www.w3.org/2008/12/11-xproc-minutes.html#action01
  27. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  28. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 11 December 2008 17:14:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 11 December 2008 17:14:19 GMT