XProc Minutes 23 July 2009

See http://www.w3.org/XML/XProc/2009/07/23-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 150, 23 Jul 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Paul, Mohamed, Norm, Vojtech, Henry

   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: telcon 30 July 2009
         4. [8]Recent comments on the CR draft
         5. [9]142 charset on unescape-markup?
         6. [10]144 Semantics of p:wrap
         7. [11]145 Compound steps with unconnected output ports
         8. [12]146 Primary output port in p:viewport
         9. [13]147 primary output ports
        10. [14]Default XML processing model?
        11. [15]Test suite progress?
        12. [16]Any other business?

     * [17]Summary of Action Items

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

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

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

   Accepted.

  Next meeting: telcon 30 July 2009

   Mohamed gives regrets.

  Recent comments on the CR draft

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

  142 charset on unescape-markup?

   Vojtech: I wasn't sure what the user was trying to do.

   ->
   [21]http://lists.w3.org/Archives/Public/xproc-dev/2009Jul/att-0042/00-part

   Vojtech: I think unescape markup ignores the charset information if the
   content type is a text type.
   ... It only uses the charset information when the data is base64 encoded,
   to decode the data.
   ... I propose two solutions.
   ... The output of unescape markup used the wrong charset.
   ... It only uses charset if the data is binary and base64 encoded.
   ... To make sure that the charset is used, use p:data and set the
   content-type to something binary. That assures that the data is base64
   encoded and the charset will be used when decoding the data.
   ... The other solution is similar, in p:data set the charset so that
   p:data applies the right charset encoding.

   Norm: Yes.
   ... I think that if he got XML that was incorrectly encoded, that's a bug.

   Vojtech: It depends how he passed that data to unescape-markup.

   Norm: If p:data was used, then the charset should have been used when
   loading the data.
   ... If p:http-request was used and the return type was something Unicode,
   then the charset should have been used.
   ... If the return type was binary, then the result should have been base64
   encoded and the charset should have been used when expanding that.
   ... I can't think of any way to get data in the wrong character set into
   p:unescape-markup that isn't an implementation bug.
   ... We're equally careful in p:http-request and p:data, so I think this is
   just a bug.

   Vojtech: I tried these approaches in Calumet and they worked.

   Norm: Ok, I think that makes it clear that this is an implementation error
   in XML Calabash

   Vojtech: Related to this, I have a question about p:data. If you use
   p:data to load a text file that's in Windows-1252 then p:data converts it
   to Unicode characters.
   ... But at least in our implementation, the charset implementation still
   remains in the c:result wrapper.
   ... I wonder if that's correct.

   Norm: In p:http-request, we're explicit that the content-type value must
   be an exact copy of the response header.
   ... In p:data, we have the added complication that sometimes we ahve to
   infer a content type. But we should probably say that it should be an
   exact copy if we do have one.

   Vojtech: Even when inferring a content type you could do some magic to
   infer the charset.

   Norm: I think we should add the same clarification here that we have in
   p:http-request, that the content type will reflect any charset specified
   even in the case where those characters have been converted to Unicode.

   Proposal: do that

   Accepted.

   <scribe> ACTION: Norm to update the spec to specify the charset in p:data
   to be as explicit as it is in p:http-request. [recorded in
   [22]http://www.w3.org/2009/07/23-xproc-minutes.html#action01]

   That covers 143 as well.

  144 Semantics of p:wrap

   Norm: The semantics of p:wrap are intended to be recursive, unlike what I
   initially said.

   Accepted.

   Close without action.

  145 Compound steps with unconnected output ports

   Vojtech summarizes his email.

   Norm: I think the answer is that you get an empty sequence if you try to
   read it.

   Vojtech: And if sequence=false, then you get a dynamic error?

   Norm: Yes, I think that's the case.

   Vojtech: There's discussion of this in p:for-each but not generally

   Norm: Right, I think we need a general statement.
   ... Proposed: unbound output ports on a compound step return an empty
   sequence when they're read, it's an error if they don't specify
   sequence=true

   Accepted.

   <scribe> ACTION: Norm to say this in the spec. [recorded in
   [23]http://www.w3.org/2009/07/23-xproc-minutes.html#action02]

  146 Primary output port in p:viewport

   Vojtech: In viewport you can specify one output port. The spec says that
   p:viewport must contain a single primary output port.
   ... So do I have to set it primary explicitly, or is will it default to
   primary?

   Norm: Yes, it will default to primary=true

   Vojtech: A second question: suppose you have a declare-step and you
   declare two output ports.
   ... According to the rules, the other output port will be non-primary.

   <p:declare-step>

   <p:output port="one"/>

   <p:output port="two" primary="false"/>

   </p:declare-step>

   General agrement: both are non-primary.

  147 primary output ports

   Norm explains.

   Vojtech: There's an implicit pipe binding in the p:with-option, so I think
   it's bound.

   Norm: Yes, I think you're right.

   Proposal: yes, that counts.

   Mohamed: I don't think it's sufficient for cycle checking.

   Norm: I think it is sufficient for cycle testing, there's a dependency
   between them.

   <scribe> ACTION: Norm to attempt to clarify this in the spec. [recorded in
   [24]http://www.w3.org/2009/07/23-xproc-minutes.html#action03]

  Default XML processing model?

   No news, it'll be a while before we can return to this.

  Test suite progress?

   Norm: Vojtech gets a gold star for some truly tortuous tests this week.
   ... I think some of the burden is on my to update the coverage report.

   Vojtech: For tests for unconnected output ports, there is no well-defined
   static error for this case.

   Norm: Right!
   ... I made unconnected input ports static error and unconnected output
   ports static error 3.
   ... We should look through the spec and make sure that there's an error
   code for every MUST and MUST NOT.

   Vojtech: I'll do the review.

  Any other business?

   None heard.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Norm to attempt to clarify this in the spec. [recorded in
   [25]http://www.w3.org/2009/07/23-xproc-minutes.html#action03]
   [NEW] ACTION: Norm to say this in the spec. [recorded in
   [26]http://www.w3.org/2009/07/23-xproc-minutes.html#action02]
   [NEW] ACTION: Norm to update the spec to specify the charset in p:data to
   be as explicit as it is in p:http-request. [recorded in
   [27]http://www.w3.org/2009/07/23-xproc-minutes.html#action01]

   [End of minutes]

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

    Minutes formatted by David Booth's [28]scribe.perl version 1.135 ([29]CVS
    log)
    $Date: 2009/07/23 16:45:35 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/07/23-agenda
   3. http://www.w3.org/2009/07/23-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/07/23-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/07/23-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/07/23-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/07/23-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/07/23-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/07/23-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/07/23-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/07/23-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/07/23-minutes#item08
  13. http://www.w3.org/XML/XProc/2009/07/23-minutes#item09
  14. http://www.w3.org/XML/XProc/2009/07/23-minutes#item10
  15. http://www.w3.org/XML/XProc/2009/07/23-minutes#item11
  16. http://www.w3.org/XML/XProc/2009/07/23-minutes#item12
  17. http://www.w3.org/XML/XProc/2009/07/23-minutes#ActionSummary
  18. http://www.w3.org/XML/XProc/2009/07/23-agenda
  19. http://www.w3.org/XML/XProc/2009/07/16-minutes
  20. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  21. http://lists.w3.org/Archives/Public/xproc-dev/2009Jul/att-0042/00-part
  22. http://www.w3.org/2009/07/23-xproc-minutes.html#action01
  23. http://www.w3.org/2009/07/23-xproc-minutes.html#action02
  24. http://www.w3.org/2009/07/23-xproc-minutes.html#action03
  25. http://www.w3.org/2009/07/23-xproc-minutes.html#action03
  26. http://www.w3.org/2009/07/23-xproc-minutes.html#action02
  27. http://www.w3.org/2009/07/23-xproc-minutes.html#action01
  28. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  29. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 23 July 2009 16:47:17 UTC