See also: IRC log
Date: 25 March 2015
<scribe> Meeting: 267
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2015/03/25-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2015/03/11-minutes
Accepted.
Proposed: 1 April 2015 does anyone have to give regrets?
No regrets heard. Possible regrets from Henry, I can't recall for sure.
Jim: I spent some time on mine, but haven't got anything ready for review yet.
No other progress reported.
-> Topic: Review of open action items
-> https://github.com/xproc/specification/issues/43
Norm proposes that there's insufficient support.
Jim wonders about new users.
Norm notes that it isn't in XSLT
Jim: I'm not sure that the XSLT user is the only thing we should consider, but I'm not sure this wins us very much.
Proposal: Close without action.
Any objections?
None heard.
-> https://github.com/xproc/specification/issues/148
Jim: This came up in
conversations at XML Prague.
... This is day 0 concerns, more than after you've learned it
all.
... Today, if you're a new user, to get a document into a
database, you need to understand a lot of topics. That can give
a negative impression.
... I wonder, now that we've considered multipart in other
places, if we could accept glob values.
... That could help new users. And if we like it there, what
about p:document as well.
... If we're going to change primitives, how does that hook
into a higher level, like a database or webdav or
anything.
... I think after I talked to people about it, we're just
looking at a simple change.
... This also applies to some event driven stuff. But that's
probably out of scope for 2.0.
... In the end, I wonder if we can't do something simple.
Norm: Yeah, this came up as a comment in my proposal for p:document and p:load as well.
Norm waffles on about some sort of filter element inside inputs.
Jim: I think the filter is an
interesting idea. We allow everything to be composed from the
ground up, but I wonder where the primitives should be.
... Doesn't content-type apply to multipart.
Some discussion of Norm's proposal for p:document and p:load (item 7 on today's agenda)
Norm observes that we could have a dtd-validate step now that we have the ability to have non-XML documents flowing through the pipeline.
Alex proposes that we should try to define things like p:load in terms of other subpipelines.
-> https://github.com/xproc/specification/issues/145
-> https://ndw.github.io/specification/langspec/clarify-load/head/xproc20/diff.html#p.document
-> https://ndw.github.io/specification/langspec/clarify-load/head/xproc20-steps/diff.html#c.load
Norm walks through what he's done.
<alexmilowski> missing a space in the p:load descritption
Jim: A question about http-request came up while reading this. How do we deal with a GET on collections?
Norm: I don't think we do anything, there's no notion of collections in HTTP. We could write a webDAV step, but I think that'd be a different step.
Jim: Globbing wouldn't do anything on an http request.
Norm: Right.
Alex: I'd say building in magic is a bad idea.
Norm: Is globbing on file URIs magic?
Alex: That's different. The directory is a thing you can talk to. It has a POSIX API etc.
<alexmilowski> (finally, coffee!)
Norm: How about I try to tighten this up a bit, add a p:dtd-validate step along the lines we discussed, add globbing, and possibly add the filtering stuff I described.
No one objects to norm doing more work.
<scribe> ACTION: Norm to make p:load more explicitly like http-request, perhaps by adding a dtd-validate step and describing a pipeline that can use it. He'll also add globbing for file: URIs and perhaps the filtering stuff we discussed. [recorded in http://www.w3.org/2015/03/25-xproc-minutes.html#action01]
<scribe> ACTION: Norm to make sure that the case of casting multipart to single part is covered; Alex believes that binaries are base64 encoded in multipart documents (so that the boundary isn't borked) [recorded in http://www.w3.org/2015/03/25-xproc-minutes.html#action02]
->https://github.com/xproc/specification/issues/116
-> http://www.w3.org/TR/xproc20-steps/#c.cast-content-type
Alex: There are two possible expectations: what the step currently says, and that the server lied and I want to parse it as XML.
Norm: So I think what you want is a step that just attempts to parse it.
Alex: There's the thing and the representation of the resource and which do we mean.
Norm: So we want
p:cast-content-type to attempt to parse, not make a base64
encoded anything.
... We have (at least proposed) steps for base64
encoding/decoding.
Alex: If you take octet stream and cast to image, maybe that will work, maybe it won't, it's going to be implementation-defined or -dependent.
Norm: So should this step take parameters?
Alex: It would be nice not to have steps that overlap in strange ways.
<jfuller> quote/unquote ?
Norm: So p:cast-content-type should try to do everything. Including base64 encode and decode.
Alex: I think the word "cast" is
misleading.
... We're trying to minimally change the content type and
that's not the same as the concept of "casting". Casting
implies some sort of type system and we just don't have
that.
... Getting from thing it was labeled to thing we want it to be
should be something else.
Norm: Unfortunately, we've run out of time.
Adjourned.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Norm Alex Jim Regrets: Henry Loren Murray Agenda: http://www.w3.org/XML/XProc/2015/03/25-agenda Found Date: 25 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/25-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]