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

XProc Minutes 7 Feb 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 07 Feb 2008 12:14:05 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2fxw44rky.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/02/07-minutes

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 101, 07 Feb 2008

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Paul, Norm, Henry, Rui, Richard, Alex, Andrew, Murray [x:45-]

   Regrets
           Alessandro, Mohamed

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 14 February 2008?
         4. Last call comments
         5. Excluding prefixes on p:inline
         6. p:label-elements proposal from Alex
         7. #108. Serialization parameters as parameter input ports
         8. 110. Add dates to schema docs
         9. #109. Response headers is in p:http-request
        10. 112. Propose a warning mechanism.
        11. #113. Nitpicking p:insert and p:add-attribute
        12. Any other business?
     * Summary of Action Items

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

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/02/07-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/01/31-minutes

   Accepted.

  Next meeting: telcon 14 February 2008?

   No regrets given

  Last call comments

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

  Excluding prefixes on p:inline

   Norm attempts to summarize.

   Norm: Do we want to make it possible to exclude prefixes?

   Henry: What's wrong with telling processors they should construct
   documents as if serializing the document, removing all inherited namespace
   bindings from the root, and reparsing?
   ... That is, remove everything that's inherited.
   ... In the 0.1 percent case, you'd have to bind a namespace several times
   because you were using it in several inlines.

   Norm: That seems way more confusing than just adding the attribute.

   Alex: Considering we have to produce a document from p:inline, you have to
   do a little bit of work. So having to do a little more work doesn't seem
   that bad.

   Henry: If you've got an infoset, you're going to have to walk through and
   fix all the nodes.

   Alex: I don't think so.

   Henry: In order to prevent serialization from doing the wrong thing
   further down the line, you're going to have to look at all the namespace
   information bindings.

   Some discussion of how complicated this really is.

   <ht> http://www.w3.org/TR/xslt20/#lre-namespaces[7]

   Henry: What that says is you've got to walk the tree and prune the
   namespace nodes.

   Richard: XSLT's mechanism is slightly more complicated than the excluded
   prefixes; the xsl: prefix is excluded and then there's an alias that lets
   you put it back in.

   Norm: Bah.

   Alex: I wonder if there's a simple thing that we have a problem with: the
   document element is going to inherit all the in-scope namespaces. The
   simple question is, do we break that relationship?

   Henry: The argument that says inline is very-very parallel to literal
   result elements in XSLT suggests we should make it very parallel.

   <alexmilowski> +1 to that.

   Henry: We exclude the pipeline namespace, we provide
   exclude-result-prefixes, and we add the aliasing.
   ... If we think it's parallel to XSLT LREs, we should change things to
   make it parallel.

   <ht> HST didn't say 'add the aliasing', but might be persuaded. . .

   Henry: Because we can stand in a better place, I'm going to try to do it
   the following way:
   ... what the ... nevermind
   ... what I was going to say was that we exclude them from this element
   where they're inherited. But that's too hard and complicated.

   <scribe> ACTION: Henry to draft a spec change for providing
   exclude-result-prefixes on p:inline. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action01[8]]

   Richard: We don't need a dual to the xsl:exclude-result-prefixes
   attribute, and you only put them on a p:inline element, not on some higher
   element.

   Henry: I guess you should be able to put it on the p:pipeline or
   p:declare-step?

   Richard: No. Remember that the 90% case is you don't do this at all.

   Henry: Proposition #1, there's a dont-exclude-pipeline-namespaces
   attribute which is false by default. Or there's an
   exclude-pipeline-namespaces attribute which is true by default.

   Richard: Is it used for anything else in XSLT?

   Henry asserts its not

   Richard reads something from the XSLT spec about security and namespace
   aliasing.

   Scribe distracted for a moment

   Richard proposes using another step if you really need to have the
   pipeline namespace.

  p:label-elements proposal from Alex

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Feb/0017.html

   Alex summarizes the proposal, including an addition to control replacement

   Henry: Remind me, did we reach closure on a variable versus a function?

   Alex: I think those of us who wanted this change wanted the variable.
   ... My rationale is that some APIs make it easier to set a variable than a
   function.

   Henry: As we've repeatedly commented, implementations don't have to use
   XPath at all in the defaulted case.
   ... It's easy to optimize this if you want to.

   Alex: One tweak is to say that the label attribute is optional

   Some discussion of function vs. variable.

   Alex: Inside a step, it seems like you need an API that you might not
   otherwise need inside the step. Things like viewport can be very
   different. The API for steps might be simpler, cleaner.
   ... Writing things in steps seems different than writing things in the
   core language.

   Shall we adopt Alex's proposal?

   Accepted.

   Alex: With a replace option?

   Norm: I think so, any objections?

   None heard.

  #108. Serialization parameters as parameter input ports

   Norm: I think this is a desire to compute serializatin parameters and pass
   them in dynamically. Maybe useful, but not a V1 feature in my mind.

   Henry: Besides, there's a workaround.
   ... You can write the document and the compute the options from that
   document.

   Proposal: No change to support this use case in V1.

   Accepted.

   <scribe> ACTION: Alex to reply to the submitter. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action02[10]]

  110. Add dates to schema docs

   Norm: I don't know why I put this on the agenda, it's editorial. Let's
   just do it.

   Accepted.

  #109. Response headers is in p:http-request

   Alex: I think we should drop the ommission of content-* headers.
   ... I don't think I want to go into parsing the headers because the header
   parsing is dependent on the header, they don't all take parameters.
   ... I think its overkill even if it is generally true. And I don't think
   you'd gain anything.
   ... in the case of charset, the parameter has already been used to decode
   the content.

   <scribe> ACTION: Alex to consider any clarifications that might need to be
   made to p:http-request. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action03[11]]

   At the very least, go ahead and remove the restriction on content-*
   headers.

   Topic #111. Additions to implementation defined section

   Norm: I suggest that we whatever XPath 2.0 does wrt Unicode versions.

   <scribe> ACTION: Norm to add the Unicode version text to the spec
   [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action04[12]]

  112. Propose a warning mechanism.

   Norm: I don't think we need to say anything about warnings, but I'm
   prepared to be persuaded.

   Alex: Programs can generate warnings if they want.

   Proposed: We'll say nothing in the spec about this.

   Accepted.

  #113. Nitpicking p:insert and p:add-attribute

   Norm is inclined to agree with the commenter

   Richard: What does add-attribute do if the attribute is already present

   Norm: We don't say. That we need to fix.
   ... Let's take these one at a time.
   ... Are we going to rename add-attribute to insert-attribute?

   Alex: I'm not sure insert is the right word

   Norm: I don't hear any support.
   ... So I'm inclined to leave insert the way it is; we might relax the
   restrictions in the future.

   Richard: And if the document has a PI, then that gets inserted, so we
   can't rename it insert-element.

   Alex: And we can have before and after, so it isn't a child.

   Proposal: do nothing.

   <scribe> ACTION: Alex to fix add-attribute wrt existing attributes
   [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action05[13]]

   <scribe> ACTION: Alex to fix insert so that it doesn't always imply child.
   [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action06[14]]

   Accepted.

  Any other business?

   None.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Alex to consider any clarifications that might need to be
   made to p:http-request. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action03[15]]
   [NEW] ACTION: Alex to fix add-attribute wrt existing attributes [recorded
   in http://www.w3.org/2008/02/07-xproc-minutes.html#action05[16]]
   [NEW] ACTION: Alex to fix insert so that it doesn't always imply child.
   [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action06[17]]
   [NEW] ACTION: Alex to reply to the submitter. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action02[18]]
   [NEW] ACTION: Henry to draft a spec change for providing
   exclude-result-prefixes on p:inline. [recorded in
   http://www.w3.org/2008/02/07-xproc-minutes.html#action01[19]]
   [NEW] ACTION: Norm to add the Unicode version text to the spec [recorded
   in http://www.w3.org/2008/02/07-xproc-minutes.html#action04[20]]
    
   [End of minutes]

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

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/02/07-agenda
   [3] http://www.w3.org/2008/02/07-xproc-irc
   [7] http://www.w3.org/TR/xslt20/#lre-namespaces
   [8] http://www.w3.org/2008/02/07-xproc-minutes.html#action01
   [10] http://www.w3.org/2008/02/07-xproc-minutes.html#action02
   [11] http://www.w3.org/2008/02/07-xproc-minutes.html#action03
   [12] http://www.w3.org/2008/02/07-xproc-minutes.html#action04
   [13] http://www.w3.org/2008/02/07-xproc-minutes.html#action05
   [14] http://www.w3.org/2008/02/07-xproc-minutes.html#action06
   [15] http://www.w3.org/2008/02/07-xproc-minutes.html#action03
   [16] http://www.w3.org/2008/02/07-xproc-minutes.html#action05
   [17] http://www.w3.org/2008/02/07-xproc-minutes.html#action06
   [18] http://www.w3.org/2008/02/07-xproc-minutes.html#action02
   [19] http://www.w3.org/2008/02/07-xproc-minutes.html#action01
   [20] http://www.w3.org/2008/02/07-xproc-minutes.html#action04
   [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [22] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[21] version 1.133 (CVS
    log[22])
    $Date: 2008/02/07 17:13:13 $

Received on Thursday, 7 February 2008 17:14:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2008 17:14:25 GMT