XProc Minutes 19 Mar 2014

See http://www.w3.org/XML/XProc/2014/03/19-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 245, 19 Mar 2014

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Henry, Vojtech, Alex, Jim

   Regrets

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: 26 Mar 2014
         4. [8]Review of open action items
         5. [9]Review response to bug 21005
         6. [10]Review proposed errata
         7. [11]Bugs against 1.0
         8. [12]Any other business?

     * [13]Summary of Action Items

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

  Accept this agenda?

   -> [14]http://www.w3.org/XML/XProc/2014/03/19-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> [15]http://www.w3.org/XML/XProc/2014/03/05-minutes

   Accepted.

  Next meeting: 26 Mar 2014

   No regrets heard.

   Vojtech gives regrets for 26 Mar

  Review of open action items

   Norm has done some of his, see the errata document

  Review response to bug 21005

   -> [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21005

   Jim proposes adding a may requirement to make static compilation possible.

   Norm proposes that it should be a should at least.

   Norm muses about why we have "optional options". In XPath 2.0 I think we
   have more leeway because we can say that the default value is the empty
   sequence.

   The fact that XProc 1.0 conflates the notion of variable binding

   across the static and dynamic contexts means that attempting

   to compile XPath expressions in a purely static way will still

   require determining whether or not there are bindings for all

   the XPath variables at runtime.

   <jfuller> +1

   <ht> +1

   <alexmilowski> +1

   <ht> or /variables in the expression/

   Norm: I added that to the bug. We'll see what the commenter says and get
   back to adding errata shortly.

  Review proposed errata

   ->
   [17]http://htmlpreview.github.io/?https://github.com/xproc/specification/blob/xproc10/10errata/proposed.html

   Vojtech: The first comment I had was about p:choose;

   ->
   [18]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Mar/0016.html

   Vojtech explains.

   Norm: I think you're correct.

   <jfuller> 'to invoke'

   <jfuller> ?

   Vojtech: Sometimes we say 'connected' and sometimes we say 'bound' and we
   don't clearly define those terms.

   Henry: I agree absolutely.

   Vojtech: Does connected meaning consumed or consuming?

   <ht> "If a (non-primary) output port of a compound step is left
   unconnected"

   Norm: I have an action to fix that.

   <ht> "An output port may have more than one connection: it may be
   connected to more than one input port,"

   Norm: But I hadn't seen the connection to bound.

   Vojtech: In 2.2 you end up with a different picture depending on which
   side you look at.

   Henry: In 2.2, three paragraphs apart, one use of connection is pull and
   one is push.

   <ht> So I'm glad to hear that Norm has an action to fix this

   Vojtech: Another distinction between connected and bound: for output ports
   it is an error if they remain unconnected. That made me realize that
   connected means being consumed.

   Norm: It just means ... connected

   Vojtech: If you look at it from an implementation standpoint, pull or
   push, it can be different.

   <ht> Not just connected -- for _compound_ steps, the output port can be
   connected twice

   <ht> ... Once to pull its value

   <ht> ... The other to push its value

   Norm: Thank you, I see the problem more clearly now.

   <ht> Yes, yes we are

  Bugs against 1.0

   -> [19]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21053

   In the p:wrap case, unless you wrap "/", the base URI doesn't change.
   Right?

   <jfuller> what does p:base-uri() return

   <ht> Base URI changes all over a document

   <ht> If you mean the base URI property in the infoset

   In the p:wrap case, unless you wrap "/", the base URI property of the
   document in the infoset doesn't change.

   Do we agree with that?

   <ht> NOOOOIO

   <ht> Because it's _elements_ that have base URIs!

   Don't document infoset items have base URIs?

   Vojtech: It feels to me that in p:wrap-sequence alone, if you wrap a
   single document or 10 the base URI of the result should be consistent.

   Norm: in the wrap-sequence case where we're creating a whole new document
   with a new root element

   Alex: I think it should be empty

   <ht> NOTE: This is wrong, in the def'n of p:xinclude: "The included
   documents are located with the base URI of the input document and are not
   provided as input to the step."

   <ht> We're not talking about document URI

   <ht> +1

   Norm: I think I heard "empty" as the proposed value for base-uri from
   p:wrap-sequence, does anyone disagree?

   None heard.

   Norm: I think a p:wrap that wraps "/" should behave exactly like
   p:wrap-sequence on that document, does anyone disagree?

   None heard.

   <ht> Note that that is _only_ on the document node and the document
   element node

   Henry: We need to fix XInclude. We're being too glib in talking about
   base-URIs. All of the elements in the document potentially have base-uri
   properties.

   We shouldn't think about fixing this without doing fixup.

   Henry: the part about the base-uri property is that it provides the base
   for resolving URI references.
   ... It doesn't get copied but you have to look up the chain to your
   ancestors until you find a base URI

   <jfuller> base uri fixup reference -
   [20]http://www.w3.org/TR/2004/REC-xinclude-20041220/#base

   Henry: What that makes me think is that the result should have a base URI
   on the document node and that's it.
   ... It follows that if you wrap it, in order to make the relative
   references work, you should copy the base URI onto the element that used
   to be the document element and is now submerged.

   Alex: If you think of it conceptually, they're equivalent to "this
   XInclude" where this document has no URI/base-uri. Or it's embedded.
   ... I wonder if the outcome is similar.
   ... If you look at it from an XInclude perspective is it similar, is it
   the same.

   <jfuller> the right base uri fixup reference - base uri fixup reference

   <jfuller> [21]http://www.w3.org/TR/xinclude/#base

   Alex: It would be nice if these things could work in the same way. We need
   to think this through more carefully.

   Norm: I'll make this base URI question an explicit agenda item for next
   week.

  Any other business?

   Adjourned.

Summary of Action Items

   [End of minutes]

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

    Minutes formatted by David Booth's [22]scribe.perl version 1.138 ([23]CVS
    log)
    $Date: 2014-04-23 00:03:19 $

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

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]

 This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
 Check for newer version at [24]http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

 Guessing input format: RRSAgent_Text_Format (score 1.00)

 Succeeded: s/variables/XPath variables/
 Succeeded: s/it/the base URI/
 Succeeded: s/emtpy/empty/
 Found Scribe: Norm
 Inferring ScribeNick: Norm
 Found ScribeNick: Norm
 Present: Norm Henry Vojtech Alex Jim
 Agenda: [25]http://www.w3.org/XML/XProc/2014/03/19-agenda
 Found Date: 19 Mar 2014
 Guessing minutes URL: [26]http://www.w3.org/2014/03/19-xproc-minutes.html
 People with action items:


   [End of [27]scribe.perl diagnostic output]

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2014/03/19-agenda
   3. http://www.w3.org/2014/03/19-xproc-irc
   4. http://www.w3.org/XML/XProc/2014/03/19-minutes#agenda
   5. http://www.w3.org/XML/XProc/2014/03/19-minutes#item01
   6. http://www.w3.org/XML/XProc/2014/03/19-minutes#item02
   7. http://www.w3.org/XML/XProc/2014/03/19-minutes#item03
   8. http://www.w3.org/XML/XProc/2014/03/19-minutes#item04
   9. http://www.w3.org/XML/XProc/2014/03/19-minutes#item05
  10. http://www.w3.org/XML/XProc/2014/03/19-minutes#item06
  11. http://www.w3.org/XML/XProc/2014/03/19-minutes#item07
  12. http://www.w3.org/XML/XProc/2014/03/19-minutes#item08
  13. http://www.w3.org/XML/XProc/2014/03/19-minutes#ActionSummary
  14. http://www.w3.org/XML/XProc/2014/03/19-agenda
  15. http://www.w3.org/XML/XProc/2014/03/05-minutes
  16. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21005
  17. http://htmlpreview.github.io/?https://github.com/xproc/specification/blob/xproc10/10errata/proposed.html
  18. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Mar/0016.html
  19. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21053
  20. http://www.w3.org/TR/2004/REC-xinclude-20041220/#base
  21. http://www.w3.org/TR/xinclude/#base
  22. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  23. http://dev.w3.org/cvsweb/2002/scribe/
  24. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
  25. http://www.w3.org/XML/XProc/2014/03/19-agenda
  26. http://www.w3.org/2014/03/19-xproc-minutes.html
  27. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Wednesday, 23 April 2014 00:08:43 UTC