<jfuller> I can hear ... my audio is fracked

Accept this agenda?

-> http://www.w3.org/XML/XProc/2015/03/11-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2015/02/25-minutes

Accepted.

Next meeting

Any regrets for 18 Mar?

None heard.

<jfuller> still working on A-265-02

Content type on p:load, issue 145?

Norm: I think this is just an oversight. Anyone disagree?

Alex: It would be a kind of overload.

Norm: This is really about making p:load handle non-XML documents.
... I'll update the issue.

<jfuller> what does p:load do with multipart ?

Norm: I'll add multipart to the issue as well.

Alex: We should look at this in light of p:http-request so that they're in line with each other.

<jfuller> is the result port explicitly a single document ?

<jfuller> as in not a sequence

Norm: It could (should) be a sort of short-cut for a simpler p:http-request with only a GET and handling file: etc.

Alex: Yes.

<jfuller> part of https://github.com/xproc/specification/issues/148 we are avoiding discussing today

<jfuller> suggests some enhancements to p:load

<jfuller> (will feed via that issue)

Ok. We can talk about that when you have audio :-)

<jfuller> +1

Content type of p:inline issue 144?

Norm: I guess this is really about inlining non-XML
... You could have a JSON blob inline or something.

Alex: We should consider a number of use cases, things that have text encodings: JSON, SPARQL, etc.
... It would also be good to be able to inline data. Small images, etc.

Norm: I think we'd have to have some base64 encoding trick.
... So p:inline should be sort of like p:load with the data just inline, maybe encoded.

<jfuller> is content-type equal to setting content-type document property - if so do we want a more general mechanism for setting property values (consider can of worms opened on that one)

We already have an issue on that, I think.

Norm mutters something about encoding non-XML, non-text formats

Alex: That might be true today but we should consider other image formats for example that might be text.

<jfuller> I will take that

Clarify the concept of "URI appearing in an option value, issue 143.

<jfuller> https://github.com/xproc/specification/issues/143

Norm: I think this is interesting. I think this means we have to specify the type of some attributes as xs:anyURI so that the processor knows which ones are URIs.

Alex: Yes.

Reading document properties in a step-evaluated XPath issue 138?

Norm explains the background.

<jfuller> https://github.com/xproc/specification/issues/138

Norm: I'm not sure this makes any sense, really. Most of the p:* functions don't make any sense outside the context of the processor.

<jfuller> On 2nd read I think our status quo is ok and we close this issue

<jfuller> can't p:filter be used to achieve this logic ? confused

Norm: I just think we have to stick with the status quo.

Alex: It seems like a limitation we should think harder about.

Norm: I think absent a proposal that describes how we could do this in a practical way, we're not going to be able to.

Alex: I think the right way would be to put those functions into the steps. But that would be a burden on implementors.
... Where in our current vocabulary does this occur?
... I think we need to think hard about the burden on implementors but the right answer for users is to say that the same functions are available everywhere.
... We should update the issue.

<scribe> ACTION: A-266-01 Alex to update issue 138 with an outline of what needs to be covered by a proposal to make the functions more broadly available [recorded in http://www.w3.org/2015/03/11-xproc-minutes.html#action01]

Any other business?

None heard

Adjourned.