- 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
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 204, 15 Dec 2011
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Paul, Jim, Carine, Cornelia, Vojtech, Alex, Henry
Regrets
Mohamed
Chair
Norm
Scribe
Norm
Contents
* [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
Accepted.
Next meeting: 5 January 2012.
Accepted.
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
example)
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
string.
... 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
implemetations.
... That leaves me a bit worried, frankly. But it's worth keeping in the
pot.
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
together.
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
2.1
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
application"
... 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
2.1.
Murray: I factored out the namespace qualified document and the fact that
the Core properties are repeated wasn't helpful to me.
<ht>
[18]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Dec/0014.html
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.
<jfuller>
[19]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Dec/0003.html
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
Recommendation.
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
comments.
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
log)
$Date: 2011/12/15 16:07:03 $
References
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