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

XProc Minutes 10 Sep 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 10 Sep 2009 12:26:16 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m263bq6a1j.fsf_-_@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/09/10-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 152, 10 Sep 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Paul, Mohamed, Alex, 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 17 Sep 2009
         4. [8]TPAC 2009
         5. [9]Appendix G: Handling Circular and Re-entrant Library Imports
         6. [10]Open CR issues
         7. [11]Does p:data preserve charset value for text content types
         8. [12]155/158 Appendix G.
         9. [13]159 p:choose/p:xpath question
        10. [14]160 Accomodation for JSON
        11. [15]161 Concerns about forwards-compatible mode
        12. [16]Any other business?

     * [17]Summary of Action Items

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

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

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

   Accepted.

  Next meeting: telcon 17 Sep 2009

   Mohamed gives regrets.

  TPAC 2009

   Norm: Schedule for the first week of November in Santa Clara.

   -> [20]http://www.w3.org/2009/11/TPAC/Overview.html

   -> [21]http://www.w3.org/2002/09/wbs/35125/TPAC09/

   Norm: Is anyone else planning to attend?

   Alex: I'm planning to be there, it's local for me.

   Mohamed: I'm on the fence.

   Paul: I can't make it.

   Vojtech: I'm still unsure. It depends on the status of my membership.

   Henry: Try real hard, we'd like to have you.

   Norm: Indeed.

   Vojtech: I've made good progress on getting membership restarted. Now
   waiting on the final step.

  Appendix G: Handling Circular and Re-entrant Library Imports

   ->
   [22]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Aug/att-0006/import_algorithm.html

   Henry: I think there's been no feedback on this revised version.

   Norm: Is the 4 Aug version linked above the revised version, or the
   original?

   Henry: That's the most recent one.

   Alex: The two sentences "given a pipeline library document..." and "given
   a top-level pipeline document..."
   ... I believe you mean the visited set.
   ... where you say "singleton set"

   Henry: What I understand Alex to be saying is "Given a pipeline ... it is
   an error if ... against the background of a visited set being a singleton
   set containing DU."

   Alex: Right. However you want to phrase that.

   Norm: Ok, I think this would be fine, though I'm not sure I like having
   teh defn of bag-merger in a footnote.

   <scribe> ACTION: Henry to make one more pass over the prose and insert it
   into the spec as a revised App G. [recorded in
   [23]http://www.w3.org/2009/09/10-xproc-minutes.html#action01]

  Open CR issues

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

  Does p:data preserve charset value for text content types

   Norm: I don't feel strongly, but I think it should preserve the parameters
   as p:http-request does.

   Alex: I agree.

   Mohamed: They're incorrect in UTF-8, but they aren't incorrect in Unicode.

   Alex: Is there a valid mapping from the code points to Unicode?

   General agreement that there is.

   [25]http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT

   Vojtech: My question was about encodings in general, not that specific
   one.

   Norm: I heard some agreement that we preserve the values.

   Proposal: The charset value (and other parameters) are preserved.

   Accepted.

  155/158 Appendix G.

   Resolved, see above.

  159 p:choose/p:xpath question

   Vojtech: What happens if you specify an xpath context in p:when but you
   don't specify a binding?
   ... In our implementation, the p:when is using the default readable port,
   not the binding from p:xpath-context from p:choose.

   Norm: I think this is an edge case that we didn't think of, so we just
   need to say what the answer is.
   ... Why did we allow the binding inside xpath-context to be optional?

   Vojtech: I think we might have done it to preserve the default.

   Alex: So this one uses the default context?

   Norm: I think there are two possible interpretations, an empty
   p:xpath-context either goes back to the default readable port of the
   p:choose or it goes back to the default on p:choose.
   ... Or we make it illegal by requiring a binding inside p:xpath-context.

   Vojtech: Right now the spec says it works just like p:input, so it would
   get connected to the default readable port.

   Norm: Making an empty xpath-context go back to the choose would be
   redundant.
   ... So I think that boils down to two reasonable intepretations: the
   default readable port or we make it an error.
   ... For the 1 in 999,000 case when someone might use this, I guess that
   would be ok.

   Mohamed: I think it's a bad idea, when a user uses xpath-context in the
   choose, then I think we should make the user be explicit in any p:when
   where they want a different binding.
   ... I think we should forbid having an empty p:xpath-context.

   Vojtech: I think I agree with Mohamed on this one.

   Norm: Ok by me.

   Proposal: Make it an error to leave the p:xpath-context empty.

   Accepted.

   Norm: I'll change the content model so that it's required, we don't need a
   new error code.

  160 Accomodation for JSON

   Norm: The JSON RFC doesn't define an XML encoding, it just defines JSON

   Alex: The c:query step is for XQuery, not random queries.

   Vojtech: Perhaps he meant that if the content-type on p:data was
   applicatin/json then it would be turned into XML.

   Mohamed: I don't think the purpose of this spec is to convert all
   tree-like structures into XML.

   Henry: I think this is an area where it's perfectly reasonable for
   implementors to compete. When we were doing the markup pipeline, it ended
   up being the case that it was appropriate to add a command line switch to
   upconvert STDIN from some format (like SGML) to XML.

   Norm: Yes, and I think, I'd have to go back and read carefully, that an
   impl could recognize application/json and turn it into XML.
   ... Nope, I was wrong.

   Alex: There's nothing in this message that seems to imply we're supposed
   to translate JSON into XML. We've already got ways to represent JSON in a
   pipeline, using c:data.

   Some discussion.

   Proposal: Reply that you already can include JSON as text using c:data. If
   you want conversion to XML, you'd need an extension step for that.

   Accepted.

   Some additional discussion of Henry's use case.

  161 Concerns about forwards-compatible mode

   Some discussion. General agreement that making the error dynamic rather
   than static would be very painful for implementors.

   Alex: Changing the definition of a fundamental step is a bad idea

   Norm: I think the rules we have are fine, the consequence of the rules is
   that for some changes, we'll introduce a new namespace or change the step
   name.

   Alex: So that just means he has to rearrange the choose, right?

   Norm: Right.

   Alex: So the end result would be just a slightly different pipeline.

   Proposal: Reject making the error dynamic, point out that the constraints
   are on future versions of steps with the same names, not future
   functionality.

   Accepted.

   Vojtech: I think there are two more questions. What happens if the schema
   changes so that some elements can contain new elements that weren't
   supported in V1.

   Norm: Oh, so we add a p:xyz child of steps.

   Vojtech: Not just steps, but also in p:serialization, for example.
   ... or in p:document we add a new child.

   Norm: I guess we could say that those are ignored. I have some
   reservations, but I can't articulate them.

   Vojtech: I can imagine cases where this could cause problems. What if we
   wanted to add a new kind of instruction like p:choose or p:try. If you
   ignore it then the pipeline might not make any sense anymore.

   Norm: Right so if we add p:map-reduce ignoring it would be all you could
   do but it wouldn't be the right thing.

   Mohamed: I think it has to fail.

   Norm: If we add new language elements then you can't write backwards
   compatible pipelines that use them.

   Vojtech: If you introduce a new builtin step then you could wrap it in a
   choose and use step available.
   ... No, that won't work because you have to know the signature.

   Mohamed: The problem we have is that we have to compute a new dependency
   graph. Adding new builtin constructs just makes it not backwards
   compatible.

   s/compabiel/compatible/

   scribe: I don't find it too restrictive, because when we provide a new
   instruction perhaps we can provide a wrapper step for it.

   Proposal: No, we're not going to ignore unknown elements.

   Accepted.

   Norm: And the last one is covered by the fact taht you're not allowed to
   declare steps in the p: namespace unless the URI begins with the right
   prefix.

  Any other business?

   None heard.

Summary of Action Items

   [NEW] ACTION: Henry to make one more pass over the prose and insert it
   into the spec as a revised App G. [recorded in
   [26]http://www.w3.org/2009/09/10-xproc-minutes.html#action01]

   [End of minutes]

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

    Minutes formatted by David Booth's [27]scribe.perl version 1.135 ([28]CVS
    log)
    $Date: 2009/09/10 16:23:36 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/09/10-agenda
   3. http://www.w3.org/2009/09/10-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/09/10-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/09/10-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/09/10-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/09/10-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/09/10-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/09/10-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/09/10-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/09/10-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/09/10-minutes#item08
  13. http://www.w3.org/XML/XProc/2009/09/10-minutes#item09
  14. http://www.w3.org/XML/XProc/2009/09/10-minutes#item10
  15. http://www.w3.org/XML/XProc/2009/09/10-minutes#item11
  16. http://www.w3.org/XML/XProc/2009/09/10-minutes#item12
  17. http://www.w3.org/XML/XProc/2009/09/10-minutes#ActionSummary
  18. http://www.w3.org/XML/XProc/2009/09/10-agenda
  19. http://www.w3.org/XML/XProc/2009/08/06-minutes
  20. http://www.w3.org/2009/11/TPAC/Overview.html
  21. http://www.w3.org/2002/09/wbs/35125/TPAC09/
  22. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Aug/att-0006/import_algorithm.html
  23. http://www.w3.org/2009/09/10-xproc-minutes.html#action01
  24. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  25. http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT
  26. http://www.w3.org/2009/09/10-xproc-minutes.html#action01
  27. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  28. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 10 September 2009 16:26:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 September 2009 16:26:59 GMT