See also: IRC log
Alex gives regrets.
No other progress reported.
Norm gives brief review of email thread.
Alex: Are we still XProc if we allow non-XML through the pipeline.
Norm: It doesn't worry me.
Henry: In terms of a cost-benefit
analysis in terms of update, I have a niggling worry that we've
already seen that getting your head around XProc is a barrier
to adoption. If we add this additional dimension of complexity,
it's going to get even harder.
... There's going to be another set of choices that need to be made everytime you want to do something.
Norm: I think you can run that
argument the other way too.
... Most people will eventually want to do something with non-XML so I think that complexity is also a barrier to entry.
Alex: In the case of XSLT, you
can access the resources but you can't call templates on
... One of my concerns in XProc is that even though I want to be able to process non-XML things, if we start passing non-XML around then all sorts of things might not work at runtime.
... We have to define expected behavior for non-XML at a lot of different points in the pipeline.
... It also makes us more of a data flow language and the "X" is just there for historical reasons.
... I think we need to produce use cases for non-XML documents.
Norm: Vojtech, can you send some mail summarizing some use cases?
Vojtech: It's all in the XML
Prague paper. One use cases was http-request and JSON. Another
was zip/unzip in the pipeline.
... I think there was one more too.
... Steps that produce non-XML output could produce the data on an output port and then you could do other things with them.
Norm: Formatting a PDF and sending it back as a result witout writing it to disk would be a use case.
Vojtech: I think it's really about the boundaries. It's nice if non-XML can flow through the pipeline, it makes things simpler. You don't have to pass around all these URI references to files. It's the very beginning of the pipeline where you need to read some non-XML or at the end if you want to produce non-XML.
Alex: I'm thinking of simple
examples where I want to produce some non-XML and send it via
http-request. Right now we don't have a good way to model
... Similarly, there's an issue of output. There's a distinction between the edges of the pipeline and inside the pipeline.
... It's not necessarily always the data that's flowing in between.
Jim: Developers are struggling
because we have a lot of different data models. Now we're
trying to figure out how we're going to manage all this
different data. Are you suggesting we should redefine our
internal data model? Extending XML to include other stuff? Or
do we want to keep it on the perimeter. We seem to be in a
state of flux.
... People can now have binaries and all sorts of data living very close together. The further away the data is in an operational infrastructure sense, the longer it takes to do analysis on it.
... I think there might be some utility to using XProc in hadoop.
Alex: I'm not sure we're talking
about mixing data models. The proposal from Vojtech is about
dealing with media-type-ness.
... If you have an XML media type, you get an XDM; for non-XML you get a handle to a binary blob.
Vojtech: Maybe it can be even
simpler, maybe you get non-XML data in a context where you
expect XML, then maybe what you see is an empty document. But
you have the media type so you can always tell.
... Then you don't have to extend the data model.
... You could just say that an XML infoset view on the data that flows in the pipeline produces XML for XML media types and an empty document for non-XML media types.
Norm: That seems about what I was thinking about.
Vojtech: Instead of changing XDM
we should take a simple, pragmatic approach.
... It's not full support for non-XML, it's stilly mainly an XML processing language, it just makes things easier if you get non-XML.
Norm: I wonder if we should start with a more focused use cases/requirements document
Jim: I volunteer to help edit the document.
Norm: I suggest we start with a
new document that identifies a small number of requirements
that we're considering for V.next
... Then we try to add use cases to that.
Jim: Do we have a latest link for the current doc?
Norm: Any chance we could have that skeleton done by next Monday/Tuesday.
Jim: Yes, I think so.
Alex: I'm not sure what I can do between now and then.
Norm: Alex, you had another document in mind, yes?
Alex: Yes, it might be good to
publish a note with the 1.0 solutions.
... It would be good to let everyone see how we solved the 1.0 use cases.
<jfuller> agree with Alex approach
Norm: Can you put a first draft of that together?
<scribe> ACTION: A-220-01: Alex to produce a first draft of a "XProc 1.0 Solutions" note. [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#actionx1]
Norm: I'm on the hook for a note
about OS operations; Jim, you're still on the hook for
... Are there any other documents we think it would be beneficial to publish?
Norm: We need to go through and
review these, but I'm not sure what the best strategy is
... Has anyone looked at them?
Vojtech: There are two types of
remarks: contradictions in our prose and gray areas; the others
are some interesting things that I didn't notice when I was
implementing certain features.
... There was this question about p:wrap-sequence and the group-adjacent option for example. We don't define what "the same" means.
... It's a clear whole in the spec.
Jim: He's got some simpler questions, like can we add XProc as a product to bugzilla.
<scribe> ACTION: A-220-02: Norm to ask Liam how to get XProc added to bugzilla [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#action01]
Norm: July 0000 does look easy to fix. Remove "is in no namespace" from the second sentence.
Vojtech: No, I don't think that's
... In the first sentence we say it can be in any namespace but the second says it can't be in the XProc namespace
<jfuller> +1 to that
<scribe> ACTION: A-220-03: Norm to make an erratum for July 0000 message. [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#actionx2]
Vojtech: We say that outputs of p:choose come from the subpipeline, but p:when isn't in the subpipeline.
Norm: I think we finesse the p:when case, but I'll have to take a closer look.
Vojtech: Basically, p:when is not a step.
<scribe> ACTION: A-220-04: Vojtech to investigate July 0002 and formulate an erratum to address it [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#actionx3]
<alexmilowski> Looks like we have another implementor.
<scribe> ACTION: A-220-05: Jim to investigate July 0004 and formulate an erratum to address it [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#action02]
<scribe> ACTION: A-220-06: Vojtech to investigate July 0003 and formulate an erratum to address it [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#action03]
<scribe> ACTION: A-220-07: Norm to investigate July 0005 and formulate an erratum to address it [recorded in http://www.w3.org/2012/10/04-xproc-minutes.html#action04]
Vojtech: I asked for approval to attend TPAC and I did not get it.
Norm: If you can hang out on IRC,
we'll try to keep you in the loop
... We can also try skype, google hangout, etc.
Jim: Do we have any outstanding Processor Profiles actions?
Norm: Yes, we need to get to them.
At TPAC: Norm, Jim, Henry, Mohamed, ...
Vojtech: I'll ask about Cornelia.