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

XProc Minutes 20 Oct 2011

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 25 Oct 2011 13:35:20 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2vcrdezzb.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2011/10/20-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 200, 20 Oct 2011

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Vojtech, Henry, Paul, Alex

   Regrets
           Mohamed, Jim

   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, 31 October 2011 in Santa Clara
         4. [8]XML processor profiles
         5. [9]XProc issues
         6. [10]Issue 014, can steps have foward-references?
         7. [11]Any other business?

     * [12]Summary of Action Items

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

  Accept this agenda?

   -> [13]http://www.w3.org/XML/XProc/2011/10/20-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> [14]http://www.w3.org/XML/XProc/2011/10/13-minutes

   Accepted.

  Next meeting: telcon, 31 October 2011 in Santa Clara

   Accepted. Skipping the telcon next week, meeting 31 Oct/1 Nov in Santa
   Clara

  XML processor profiles

   Henry: Some of the comments had already been addressed. Liam was
   commenting on a preceding draft.

   Norm: I was hoping to make some progress on the remaining comments, but
   didn't get the feedback I requested.
   ... I think this has to be our focus for the f2f.

   <jimfuller> Norm, if we can grab some time next week, I think we can
   punch/summarise through most of Michael's comments in about an hour, I
   hvae done my first pass and now just need a bit of your time

   <jimfuller> then we can summarise to WG

   Norm: What about the prose I wrote?

   Henry: It seems long, but I'm happy to include it.

   Norm: I propose if no one objects, we include it for the next draft. I
   think it'll help address at least a couple of comments that we have open.

   No one objects.

   <jimfuller> +1

   Norm: I'll resolve the remaining editorial issues with Paul and the pass
   it along.

  XProc issues

   -> [15]http://www.w3.org/XML/XProc/xproc-candidate-issues/

   Norm: Let's look at 013 as a place to start.

   Alex: If it's sent back as application/octet-stream, then there's no
   information lost because there's no charset.

   Norm: So maybe my first suggestion about charset param is not necessary.

   Jim: What if you want to override the charset?

   Norm: That seems a little odd to me.

   Vojtech: We now have c:body and c:data, I think that it would make sense
   if they were interchangable. The c:data has a charset attribute.
   ... Maybe it would be better if we just had c:data or c:body, but if we
   have to have both, they should be interchangable.

   Norm: We got here by adding c:data late in the process and not really
   taking the time to work out the consequences.
   ... On the basis that c:data has a charset attribute, I think c:body
   should as well.

   Alex: I'm rereading the section on converting entity bodies, which I know
   we've talked about in the past.
   ... It feels like it could be tightened. It leaves open a lot of
   interpretation; especially if you get back something from http-request.

   Norm: It also handles application/sparql and application/json.

   Alex: We said charset for text/ types, maybe we should have said it for
   non-text/ types as well.

   Norm: Ok that might be worth reviewing.

   Alex: We could at least say non-normatively that the presence of a charset
   was a good way to make assumptions about the characters.

   Norm: Let's move this up a level; is there anyone who disagrees with
   Vojtech's assertion that c:body and c:data should be interchangeable.

   Vojtech: There are at least two steps, p:xquery and p:unescape markup that
   make explicit statements about c:data, we'd have to allow c:body there as
   well.

   Norm: My inclination would be to do just that, to say everywhere that we
   use c:data that c:body is allowed and vice-versa.

   <scribe> ACTION: Norm to write a proposal to do that. [recorded in
   [16]http://www.w3.org/2011/10/20-xproc-minutes.html#action01]

   Vojtech: It has implications in how p:data and p:http-request are handled
   as well.

   Norm describes the shortcomings of p:unescape-markup as outlined in the
   message

   Norm: I think we should default the charset.

   Alex: Why can't we auto-detect?

   Norm: That turns out to be really, really hard.

   Alex: The flip side of that is, that we're guessing too. Forcing them to
   guess is good.

   Norm: Wait one sec. I did these in the wrong order. Consider my point 3
   first. If p:unescape-markup gets a c:body or c:data elment that specifies
   the encoding, then it should use that encoding without causing errors.

   General agreement.

   Norm: describes the problem of a missing encoding in that case.

   Vojtech: I think that's a problem in the step that *produced* the data.
   Fix it in the http-request.
   ... Make sure you have what you expected after you get the data.

   Alex: If you look at the specification of this step.
   ... It doesn't say anything about the element that it expects to receive.
   Now we're saying if it receives a c:body it can do something with that.
   ... I wonder if it's better to just have an option that says you should
   look at this thing and if it has certain elements or attributes, use them.
   ... For example, a content-type attribute or a charset attribute. Then you
   can have it as whatever you want.

   Vojtech: I proposed the same thing in my response.
   ... We can just have an optional option to enable or disable this
   behavior.

   Norm: Ok. I don't recall that part of the discussion. Adding an option to
   specify that the encoding and/or content type are in attributes on the
   incoming element makes sense to me.
   ... In summary: We don't want unescape-markup to default the charset, you
   have to get that right yourself, and we don't want c:data or c:body
   treated specially, we want an optional option to specify that content-type
   or encoding or charset are encoded in attributes on the root element.

   Alex: I wonder if it makes sense to categorize the different situations
   and then see what we've got.
   ... One of the cases that we don't cover well is that I have a random bit
   of markup with a content-type attribute. I have to write a pipeline to
   pick that out and get it into options.
   ... Another is the the case Norm has, where you get different responses
   from the web.
   ... It might be nice to outline solutions for the different cases and then
   see where we are.

   <scribe> ACTION: Alex to outline the various possibilities for input to
   p:unescape-markup. [recorded in
   [17]http://www.w3.org/2011/10/20-xproc-minutes.html#action02]

   Vojtech: What about 014?

  Issue 014, can steps have foward-references?

   Vojtech: I think it's the case, but it's not clear from the spec.

   Norm: I think it is the case however, if you read our import story.

   General consensus that it's a case of lazy evaluation.

   Norm: There's a related question about lazy evaluation.
   ... Can you avoid imports if you don't need them?

   Vojtech: No, because you have to report static errors.

   Norm: So you have to do it half lazily.

   Henry: Yeah, that is sort of unfortunate, but I think that's the way it
   is.
   ... It is or is not a static error to write a pipeline that invokes a step
   that isn't defined.

   Vojtech: Forwards-compatible mode is relevant here..

   Norm: In short: we do allow forward references and we do check for static
   errors.

  Any other business?

   None heard.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Alex to outline the various possibilities for input to
   p:unescape-markup. [recorded in
   [18]http://www.w3.org/2011/10/20-xproc-minutes.html#action02]
   [NEW] ACTION: Norm to write a proposal to do that. [recorded in
   [19]http://www.w3.org/2011/10/20-xproc-minutes.html#action01]

   [End of minutes]

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

    Minutes formatted by David Booth's [20]scribe.perl version 1.135 ([21]CVS
    log)
    $Date: 2011/10/25 17:34:33 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2011/10/20-agenda
   3. http://www.w3.org/2011/10/20-xproc-irc
   4. http://www.w3.org/XML/XProc/2011/10/20-minutes#agenda
   5. http://www.w3.org/XML/XProc/2011/10/20-minutes#item01
   6. http://www.w3.org/XML/XProc/2011/10/20-minutes#item02
   7. http://www.w3.org/XML/XProc/2011/10/20-minutes#item03
   8. http://www.w3.org/XML/XProc/2011/10/20-minutes#item04
   9. http://www.w3.org/XML/XProc/2011/10/20-minutes#item05
  10. http://www.w3.org/XML/XProc/2011/10/20-minutes#item06
  11. http://www.w3.org/XML/XProc/2011/10/20-minutes#item07
  12. http://www.w3.org/XML/XProc/2011/10/20-minutes#ActionSummary
  13. http://www.w3.org/XML/XProc/2011/10/20-agenda
  14. http://www.w3.org/XML/XProc/2011/10/13-minutes
  15. http://www.w3.org/XML/XProc/xproc-candidate-issues/
  16. http://www.w3.org/2011/10/20-xproc-minutes.html#action01
  17. http://www.w3.org/2011/10/20-xproc-minutes.html#action02
  18. http://www.w3.org/2011/10/20-xproc-minutes.html#action02
  19. http://www.w3.org/2011/10/20-xproc-minutes.html#action01
  20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  21. http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 25 October 2011 17:35:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 October 2011 17:35:59 GMT