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

XProc Minutes 1 May 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 01 May 2008 12:12:52 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2tzhiovej.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/05/01-minutes


                                   - DRAFT -

                            XML Processing Model WG

01 May 2008


   See also: IRC log[3]


           Norm, Paul, Alex, Mohamed, Henry, Andrew, Richard, Michael

           Rui, Vojtech




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 8 May 2008?
         4. New public working draft
         5. Update to p:www-form-urlencode
         6. Short form of p:base-uri and p:resolve-uri
         7. Support for other media types in p:unescape-markup
         8. Where are @psvi-required, @xpath-version, and
            @ignore-inline-prefixes allowed. And what are the rules for when
            they are nested?
         9. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/05/01-agenda

   Norm's affiliation changes on Monday to Mark Logic, but he anticipates
   participating as usual, without any changes.

   Let's add the items that Mohamed posted if there's time.


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/04/24-minutes


  Next meeting: telcon 8 May 2008?

   No regrets given.

  New public working draft

   Was published today!

  Update to p:www-form-urlencode


   Mohamed: I think URL encode would be useful if it could keep the content
   that is in the element that matches.
   ... The content could be, for example, the start of the URI.

   Norm: What would the option contain?

   Mohamed: My first idea was an option that says concatentate or not.

   Alex: Why not do what we did for generate-id, where we have an XPath

   Norm: Ugh. Seems like a lot of complexity for a fairly narrow case.

   <ht> So e.g. <p:w-f-e match="href"><p:with-param name="x"
   value="3"/></p:w-f-e>, with input <action

   <ht> would give <action href="http://www.example.org/service?x=3[8]"/>

   Mohamed: I don't know if the "?" is in or not.

   Norm: It's not.

   Henry: Is there an obvious way to do this otherwise?
   ... It looks useful and hard to do any other way.

   Alex: You can manipulate the parameter port beforehand in any way you

   Norm: But this is for the GET case.

   Alex: Right now you'd have to use XSLT to combine the two.
   ... I think we should keep these concerns separate, otherwise it's a
   slippery slope.
   ... We have the match because we do this operation and we have to put the
   encoded string somewhere.
   ... But outside of the scope of perform this algorithm, I'm not sure that
   we need to more.
   ... If that's the case, then we need a better insertion algorithm.

   Mohamed argues about streamability.

   Henry: Can we back up one step? I'd like to bring www-form-urldecode into
   the discussion. I think these ought to be as straightforwardly semetrical
   as we can make them.

   Some discussion of where *decode* is likely to get its input.

   Alex: It's there for symmetry. It's a bit of an edge case.

   Henry: Then I want parse URL.

   Alex: Yes, that would be good.

   Norm: You can do what Mohamed wants with url-encode and string-replace

 <p:url-form-encode name="foo">
   <p:with-param name="foo" select="'bar'"/>
   <p:with-param name="bar" select="'baz'"/>

   <p:variable name="param" select=".">
     <p:pipe step="foo" port="result"/>

   <p:string-replace match="whatever">
     <p:input port="source">
     <p:option name="replace" select="concat(.,$param)"/>

   Norm: Are you satisfied with that, Mohamed?

   Mohamed: Yes, but I think Henry has raised a good question about decoding.

   Henry: XPath 2.0 will let you do it, it'd be very hard with XPath 1.0.
   ... There's definitely a slippery slope here.

   Alex: There's a real need here, but it would be nice to have a
   URI-handling step that did a good job.

   Norm: Stop. We're way off topic, if that's a good idea, someone write a

   <ht> What we're really talking about is microparsing and generating steps,
   I realise

   So we're not changing anything about p:www-form-urlencode.

  Short form of p:base-uri and p:resolve-uri

   Norm: For consistency with XPath 2.0, I think we need to leave them.
   ... we said they'd be exactly the same as the 2.0 functions, so we
   shouldn't change them.


  Support for other media types in p:unescape-markup


   Leave until Vojtech can be present.

  Where are @psvi-required, @xpath-version, and @ignore-inline-prefixes allowed.
  And what are the rules for when they are nested?

   Proposal: Allow them all on p:pipeline, p:declare-step, and p:library.
   Also allow ignore-inline-prefixes on p:inline.

   Norm: I think a convenience for authors argument could be made for
   allowing ignore-inline-prefixes in more places, but I'm not going to make

   Mohamed: I think Jeni's point was that you could group it better if it was
   allowed anywhere.

   Richard: What about nesting?

   Norm: We don't say anything yet, that we'll have to decide.

   Henry: It's a lexically scoped union, so you can fix it.

   Norm: Any comments about where I propose to allow them?

   Mohamed: If it's allowed in p:declare-step, it will be allowed for both
   pipeline and atomic steps.

   Norm: Yes, it'll apply to default binding for p:inline.

   Some discussion of nesting for @xpath-version

   Norm: Everyone content with where I said they could go?


   Norm: I think we have a nesting story for xpath-version
   ... I think the nesting story for ignore-inline-prefixes is lexical scope
   and union.


   Henry: I think the semantics of psvi-required should be straightforward:
   if you don't have an implementation that can do PSVI, it's a dynamic error
   if you encounter one.

   Alex: If you're impl supports PSVI, then every step in your impl is using
   that API. So having a psvi-required=false doesn't mean you're not going to
   construct one.

   Norm: I think psvi-required=false is either pointless or serves only as

   Some discussion of the semantics.

   Alex: The psvi-required error is currently *static*

   Norm: I think that's silly, it should be dynamic.

   Proposed: Add a new system property that says whether or not PSVIs are
   being used by this invocation fo this pipeline.

   Accpted. Name to be determined by the editor.

   Mohamed: I think it would be better if the property just told you whether
   or not the implmentation *can* do PSVIs.

   Richard: What PSVI properties appear on documents?
   ... So a p:wrap step will throw out the PSVI properties.

   Henry: Right.

   Richard: So PSVI properties only arise from the steps that say they can
   produce them and other steps don't change them.

   Henry: I think that's right.
   ... Next week we should discuss what sort of preservation we want.

   Propsal: We make the psvi-required error a dynamic error.


  Any other business?

   None heard.


Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/05/01-agenda
   [3] http://www.w3.org/2008/05/01-xproc-irc
   [7] http://www.example.org/service?
   [8] http://www.example.org/service?x=3
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.133 (CVS
    $Date: 2008/05/01 16:11:46 $

Received on Thursday, 1 May 2008 16:13:31 UTC

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