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.

14:14:44 [Norm]

...There's going to be another set of choices that need to be made everytime you want to do something.

14:15:32 [Norm]

Norm: I think you can run that argument the other way too.

14:16:06 [Norm]

...Most people will eventually want to do something with non-XML so I think that complexity is also a barrier to entry.

14:16:09 [Zakim]

+ +420.6.026.9.aabb

14:16:15 [Norm]

zakim, aabb is jfuller

14:16:15 [Zakim]

+jfuller; got it

14:16:27 [Norm]

Alex: In the case of XSLT, you can access the resources but you can't call templates on them.

14:17:02 [Norm]

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

14:17:23 [Norm]

...We have to define expected behavior for non-XML at a lot of different points in the pipeline.

14:17:43 [Norm]

...It also makes us more of a data flow language and the "X" is just there for historical reasons.

14:18:23 [Norm]

Alex: I think we need to produce use cases for non-XML documents.

14:18:40 [Norm]

Norm: Vojtech, can you send some mail summarizing some use cases?

14:19:08 [Norm]

Vojtech: It's all in the XML Prague paper. One use cases was http-request and JSON. Another was zip/unzip in the pipeline.

14:19:21 [Norm]

...I think there was one more too.

14:20:16 [Norm]

...Steps that produce non-XML output could produce the data on an output port and then you could do other things with them.

14:20:36 [Norm]

Norm: Formatting a PDF and sending it back as a result witout writing it to disk would be a use case.

14:21:37 [Norm]

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.

14:22:38 [Norm]

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

14:23:13 [Norm]

...Similarly, there's an issue of output. There's a distinction between the edges of the pipeline and inside the pipeline.

14:23:26 [Norm]

...It's not necessarily always the data that's flowing in between.

14:24:57 [Norm]

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.

14:25:23 [Norm]

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

14:26:01 [Norm]

Jim: I think there might be some utility to using XProc in hadoop.

14:26:58 [Norm]

Alex: I'm not sure we're talking about mixing data models. The proposal from Vojtech is about dealing with media-type-ness.

14:27:22 [Norm]

...If you have an XML media type, you get an XDM; for non-XML you get a handle to a binary blob.

14:28:00 [Norm]

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.

14:28:20 [Norm]

...Then you don't have to extend the data model.

14:28:44 [Norm]

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

14:29:06 [Norm]

Norm: That seems about what I was thinking about.

14:29:26 [Norm]

Vojtech: Instead of changing XDM we should take a simple, pragmatic approach.

14:29:47 [Norm]

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

14:30:13 [Norm]

Topic: Plan for use-cases/requirements document

14:31:23 [Norm]

Norm: I wonder if we should start with a more focused use cases/requirements document

14:31:30 [Norm]

Jim: I volunteer to help edit the document.

14:33:57 [jfuller]

If Alex/Murray have a starting point for use case v2.0 doc ... pls send it along

14:33:58 [Norm]

Norm: I suggest we start with a new document that identifies a small number of requirements that we're considering for V.next