W3C

- DRAFT -

XML Processing Model WG

25 Mar 2015

Agenda

See also: IRC log

Attendees

Present
Norm, Alex, Jim
Regrets
Henry, Loren, Murray
Chair
Norm
Scribe
Norm

Contents


Date: 25 March 2015

<scribe> Meeting: 267

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Accept this agenda?

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

Accepted.

Accept minutes from the previous meeting?

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

Accepted.

Next meeting

Proposed: 1 April 2015 does anyone have to give regrets?

No regrets heard. Possible regrets from Henry, I can't recall for sure.

Review of open action items

Jim: I spent some time on mine, but haven't got anything ready for review yet.

No other progress reported.

Close issue #43 without action

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

Collector steps, issue 148

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

Clarify p:load, issue #145; see proposed changes to p:document and p:load.

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

semantics of p:cast-content-type, issue #116

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

Any other business?

Adjourned.

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-03-25 15:01:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]