Accept this agenda?

-> 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?

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

Accepted.

Next meeting: 5 January 2012.

Accepted.

V.next discussion

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

-> 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> 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> 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> 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> 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.