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

XProc Minues 15 Dec 2011

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 15 Dec 2011 11:07:33 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2hb11yg1m.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2011/12/15-agenda


                                   - DRAFT -

                            XML Processing Model WG

Meeting 204, 15 Dec 2011


   See also: [3]IRC log


           Norm, Paul, Jim, Carine, Cornelia, Vojtech, Alex, Henry





     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: 5 January 2012.
         4. [8]V.next discussion
         5. [9]XML processor profiles document
         6. [10]Any other business?

     * [11]Summary of Action Items


  Accept this agenda?

   -> [12]http://www.w3.org/XML/XProc/2011/12/15-agenda

   Norm: We'll do the V.next discussion first while we wait for Henry.

  Accept minutes from the previous meeting?

   -> [13]http://www.w3.org/XML/XProc/2011/12/01-minutes.html


  Next meeting: 5 January 2012.


  V.next discussion

   <jfuller> [14]http://www.w3.org/wiki/XprocVnext

   -> [15]http://www.w3.org/wiki/Architecture

   Norm: Let's talk about what flows between steps.

   Norm waffles a bit about XDMs.

   Norm proposes that what flows between steps are XDM instances.

   Alex: What about sequences?

   Norm: I think if a single XDM contains a sequence, that's ok.

   Some discussion of the finicky details of sequences of sequences
   (sequences of XDM nodes that themselves contain sequences of nodes, for

   Vojtech: Do we focus only on XML or do we allow other media types?
   ... Do we want to go that route, or we could say two things: either an XDM
   or a binary type of object for non-XML media types.

   Henry: Suppose instead of having binary nodes, we supported two new
   elements in the c: namespace, c:text and c:blob and defined whatever
   access we wanted to.

   Alex: We could envision these things as pointers to an input stream.

   Vojtech: To play with this, I allowed either XML or binary data flowing
   between the steps.
   ... In the step declarations for each input and output, you can specify
   the media type expected or produced. You can then pass a zip stream to
   your pipeline and if the pipeline accepts application/zip then it just
   accepts it w/o modification.
   ... If the steps are prepared to deal with it, they process it natively,
   but if the step expects XML, then the data is converted automatically by
   some implementation-defined process.
   ... It's actually very simple. There was only one change to the grammar.
   It was easy to implement.
   ... It allows you to do things like unzipping a zip file inline in the
   pipeline without using an offline or secondary storage for the files.
   ... You can create the zipfile in the pipeline and extract a file from it
   and send it to an HTTP server without any encoding.
   ... If you have a p:http-request that produces JSON, you get the real JSON
   ... By default, if the processor doesn't know how to create XML in a
   reasonable way, you get base64 encoded c:data.
   ... It was quite straightfoward and has some nice properties. The
   interesting part is how you translate between content types.

   Norm: That's very cool.

   Henry: I have mixed feelings. It sort of changes the balance between
   behavior that's well spec'd and behavior that's left in the hands of
   ... That leaves me a bit worried, frankly. But it's worth keeping in the

   Vojtech: If I release it, it will be clearly marked experimental.
   ... My concern is that it changes the balance. It's an XML processing
   language, so why are you trying to process non-XML?

   <caribou> anything about EXI?

   caribou, we should make sure EXI gets in the V.next wiki.

   Alex describes some use cases for non-XML processing in dealing with media
   in Atom feeds.

   Alex: How are we going to record all of these things for V.next?

   Norm: My plan is to build a requirements/use cases document like we did
   for 1.0

   Some discussion of the requirements document.

   <jfuller> [16]http://www.w3.org/2011/12/07-ledp-minutes.html

   Jim: I think the "Linked Enterprise Data Patterns Workshop" minutes have
   valuable input for us.
   ... I'd like to add RDF pipelines to the discussion.

   <ht> Connects up with the resource manager topic already in the wiki

  XML processor profiles document

   <ht> [17]http://www.w3.org/XML/XProc/docs/diff.html

   Norm: I think it's in good shape, congrats to the editors.

   Henry: Alex helped too.
   ... The remaining question is that I'm not happy with one set of changes.
   ... I'm not happy with the explanatory sentences at the beginning of each
   of the 2.x sections.

   Jim: Maybe those descriptions belong near the diagram?

   Henry: I sympathize with the fact that we have multiple audiences.
   ... I think the 2.x sections read more coherently if they're strung

   Jim: Norm suggested the diagram go in section 4.

   Henry: Then I think I want the textual summaries to be at the beginning of
   the end of section 2.

   Jim explains the rationale for the sentences going in the 2.x sections.

   Norm clarifies that the alternative is to put them all immediately before

   Murray: I'm fine with moving it around. I wonder about one thing: under
   each of them, the last item talks about "accurately provides to the
   ... When I wrote this up, I tried to move some of those up to the
   paragraph where we say we start with a WF/NSWF document.
   ... Most of the mention Core and ...

   Jim: I think you mean Core and ImplDef.
   ... Core and ImplDef are for the first two, and uniqueness on the last two
   is Extended.

   Further discussion of how things might be moved around.

   Norm: (While Henry looks for an email) I like the sentences and I vote
   "concur" on where they go: either in the sections or immediately before

   Murray: I factored out the namespace qualified document and the fact that
   the Core properties are repeated wasn't helpful to me.


   Jim: I got that. I didn't feel comfortable enough to put that in section 2
   because we want them to be contiguous profiles.

   The group reviews Henry's mail.

   Murray: I think having them in a group as Henry proposes (presented as a
   list) with links down to the number sections is a good idea.
   ... I've only had a chance to glance at Henry's rewording, but frankly I
   prefer mine.

   Norm: So everyone's happy with moving them up?

   No objections.


   Henry: Putting them all together seemed to increase the need to have it
   read narratively. The rewording was designed to avoid mentioning the
   technical terms.

   <jfuller> note that I had to re-interpret to match to new profile titles
   and downstream changes

   Murray: I'm not asking for mentions of properties in that list.
   ... In the introduction to section 2, it needs to be mentioned that
   starting with a NSWF document already gets you all the Core properties.
   ... Otherwise, it's confusing later.

   Henry: Unfortunately, that's not true. The XML spec doesn't mandate those.

   Murray: Short of performing 2.1 through 2.4, when one processes a NSWF
   document, one gets a set of properties.

   Henry: There's no definition of that set of properties in the XML

   Murray: Ok. But what I'll still say is that given you're able to enumerate
   the list of properties that are evident after 2.1 processing, you should
   be able to enumerate them after parsing but before 2.1.
   ... Now I'm even more confused.

   Norm: But this spec is designed to eleviate that confusion. You do what
   2.1 says and then you know where you are.

   Norm attempts to articulate a plan, then realizes we're in the a
   publishing moratorium so doesn't bother.

   Jim: I think we've dealt with Cmscmq's, Vojtech's, Paul's, and Murray's

  Any other business?

   Jim: I haven't matched up processors to the spec. I'm not there yet.
   ... I was wondering if Alex had a chance to look at the webkit stuff.

   Alex: As it stands, Webkit is basically the basic profile.

   Jim: This information is for a non-normative table.

   Henry: That can go in the document about why we aren't doing a CR.

Summary of Action Items

   [End of minutes]


    Minutes formatted by David Booth's [20]scribe.perl version 1.136 ([21]CVS
    $Date: 2011/12/15 16:07:03 $


   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2011/12/15-agenda
   3. http://www.w3.org/2011/12/15-xproc-irc
   4. http://www.w3.org/XML/XProc/2011/12/15-minutes#agenda
   5. http://www.w3.org/XML/XProc/2011/12/15-minutes#item01
   6. http://www.w3.org/XML/XProc/2011/12/15-minutes#item02
   7. http://www.w3.org/XML/XProc/2011/12/15-minutes#item03
   8. http://www.w3.org/XML/XProc/2011/12/15-minutes#item04
   9. http://www.w3.org/XML/XProc/2011/12/15-minutes#item05
  10. http://www.w3.org/XML/XProc/2011/12/15-minutes#item06
  11. http://www.w3.org/XML/XProc/2011/12/15-minutes#ActionSummary
  12. http://www.w3.org/XML/XProc/2011/12/15-agenda
  13. http://www.w3.org/XML/XProc/2011/12/01-minutes.html
  14. http://www.w3.org/wiki/XprocVnext
  15. http://www.w3.org/wiki/Architecture
  16. http://www.w3.org/2011/12/07-ledp-minutes.html
  17. http://www.w3.org/XML/XProc/docs/diff.html
  18. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Dec/0014.html
  19. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Dec/0003.html
  20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  21. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 15 December 2011 16:10:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:50 UTC