IRC log of xproc on 2015-04-01
Timestamps are in UTC.
- 13:59:47 [RRSAgent]
- RRSAgent has joined #xproc
- 13:59:47 [RRSAgent]
- logging to http://www.w3.org/2015/04/01-xproc-irc
- 13:59:50 [Norm]
- zakim, this will be xproc
- 13:59:50 [Zakim]
- ok, Norm; I see XML_PMWG()10:00AM scheduled to start in 1 minute
- 13:59:51 [Norm]
- rrsagent, set logs world-visible
- 13:59:51 [Norm]
- Meeting: XML Processing Model WG
- 13:59:51 [Norm]
- Agenda: http://www.w3.org/XML/XProc/2015/04/01-agenda
- 13:59:51 [Norm]
- Date: 1 April 2015
- 13:59:52 [Norm]
- Meeting: 268
- 13:59:53 [Norm]
- Chair: Norm
- 13:59:55 [Norm]
- Scribe: Norm
- 13:59:59 [Norm]
- ScribeNick: Norm
- 14:00:54 [Zakim]
- XML_PMWG()10:00AM has now started
- 14:01:02 [Zakim]
- +Loren_Cahlander
- 14:01:06 [Zakim]
- +[IPcaller]
- 14:02:06 [Norm]
- zakim, passcode?
- 14:02:06 [Zakim]
- the conference code is 97762 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Norm
- 14:03:35 [Zakim]
- + +1.512.761.aaaa
- 14:03:46 [Norm]
- zakim, aaaa is me
- 14:03:46 [Zakim]
- +Norm; got it
- 14:06:05 [Zakim]
- + +226256aabb
- 14:06:15 [Norm]
- zakim, aabb is Murray
- 14:06:15 [Zakim]
- +Murray; got it
- 14:08:24 [Norm]
- zakim, who's here?
- 14:08:24 [Zakim]
- On the phone I see Loren_Cahlander, [IPcaller], Norm, Murray
- 14:08:26 [Zakim]
- On IRC I see RRSAgent, Zakim, lcahlander, Norm, jfuller, liam
- 14:08:29 [Norm]
- Regrets: Henry
- 14:08:37 [Norm]
- zakim, [IPcaller is jfuller
- 14:08:37 [Zakim]
- +jfuller; got it
- 14:08:40 [Zakim]
- -Murray
- 14:08:44 [Norm]
- Present: Norm, Jim, Loren, Murray
- 14:09:01 [Norm]
- Topic: Accept this agenda?
- 14:09:01 [Norm]
- -> http://www.w3.org/XML/XProc/2015/04/01-agenda
- 14:09:01 [Zakim]
- +Murray
- 14:09:10 [Norm]
- Accepted.
- 14:09:27 [Norm]
- Topic: Accept minutes from the previous meeting?
- 14:09:27 [Norm]
- -> http://www.w3.org/XML/XProc/2015/03/25-minutes
- 14:09:29 [Norm]
- Accepted.
- 14:09:34 [Norm]
- Proposed: 8 April 2015 does anyone have to give regrets?
- 14:09:56 [Norm]
- No regrets heard.
- 14:10:36 [Zakim]
- -Norm
- 14:10:36 [jfuller]
- +1
- 14:11:39 [Zakim]
- +Norm
- 14:12:00 [Norm]
- Reminder: We have a face-to-face scheduled for Edinburgh in June.
- 14:12:34 [Norm]
- Topic: Semantics of p:cast-content-type, issue 116? (Continued from last week, review minutes.)
- 14:12:42 [Norm]
- -> https://github.com/xproc/specification/issues/116
- 14:13:05 [Norm]
- Norm attempts to summarize
- 14:14:14 [Norm]
- Norm: I think there are two interpretations: it should just change the type without doing anything else.
- 14:14:26 [Norm]
- ...or it should (sometimes) do some sort of transformation on the actual data.
- 14:14:37 [Norm]
- Norm: I don't see how the former interpretation can be implemented.
- 14:15:50 [Norm]
- Norm explains that he doesn't understand how changing from a non-xml content type to an xml content type can work without at least parsing the content!
- 14:16:30 [Norm]
- Jim: Is it equivalent to just changing the content type property (document properties)?
- 14:16:34 [Norm]
- Norm: Yes and that's forbiddne.
- 14:16:38 [Norm]
- s/ddne/dden/
- 14:17:50 [Norm]
- Murray: This is the distinction between casting and coersion, isn't it?
- 14:17:53 [Norm]
- Norm: Yes, basically.
- 14:18:52 [Norm]
- Jim: We could allow the former interpretation by letting the user change the type.
- 14:20:26 [Norm]
- Some review of the current prose in p:cast-content-type
- 14:20:36 [Norm]
- Norm wonders if we should just say it's a binary and it's implementation dependent.
- 14:20:45 [Norm]
- Jim: I think that sounds like an improvement.
- 14:21:32 [Norm]
- Norm: How about I take an action to attempt to improve it and see if we get agreeemtn.
- 14:21:34 [Norm]
- s/eee/ee/
- 14:22:36 [Norm]
- ACTION A-268-01: Norm to attempt to clarify p:cast-content-type
- 14:23:07 [Norm]
- Jim: It follows that if we say this step can set the content-type document property, are we going to allow it elsewhere?
- 14:26:00 [Norm]
- Jim: I think we need the step, I'm convinced we don't need to loosen up setting the property independently.
- 14:26:28 [Norm]
- Murray: Inside this cast step, if there has to be something done, then the cast step has to have knowledge of how to do that.
- 14:27:21 [Norm]
- Norm: It has to be something the step knows how to do.
- 14:27:45 [Norm]
- Murray: So that's why you need a coercion step inside a cast step.
- 14:27:54 [Norm]
- Norm: I think the cast step just has to know how to do the coercion.
- 14:29:42 [Norm]
- Topic: Clarify p:load, issue #145; see proposed changes to p:document, p:load, and p:http-request.
- 14:29:49 [Norm]
- -> https://github.com/xproc/specification/issues/145
- 14:31:10 [Norm]
- Norm attempts to summarize his drafts.
- 14:33:12 [Norm]
- Jim: I think these are good changes.
- 14:34:00 [Norm]
- Jim: I looked for a spec for filename globbing and didn't find it.
- 14:34:21 [Norm]
- Jim: Should we add an option to p:load to allow recursing through nested directories
- 14:34:25 [Norm]
- s/ies/ies?/
- 14:35:02 [Norm]
- Norm: We could, it feels to me like recursing directories is on the "other side of the line"
- 14:35:48 [Norm]
- Jim: I think it's a simple thing to add
- 14:37:39 [Norm]
- Murray: Being able to list just the files that I want would also be useful.
- 14:38:54 [Norm]
- ACTION A-268-02: Jim to create an issue for recursion in p:load with a note of the question about enumerating a list of files
- 14:40:06 [Norm]
- Topic: Norm's proposal for filtering inputs, see p:filter.
- 14:40:12 [Norm]
- Norm attempts to summarize
- 14:40:46 [Norm]
- https://ndw.github.io/specification/langspec/input-filter/head/xproc20/diff.html#p.filter
- 14:43:36 [Norm]
- Norm: Like filtering in things like ant and gradle, it just simplifies things.
- 14:43:53 [Norm]
- Jim: I think the idea is spot on, but I have some questions about why it's a child of p:input.
- 14:44:16 [Norm]
- ...The idea of having multiple p:filters...what does ordering do?
- 14:45:26 [Norm]
- Norm: I removed the interleave problem.
- 14:46:05 [Norm]
- Jim: How about a top-level definition of the filter that you can reuse?
- 14:46:46 [Norm]
- Norm: I sort of thought that the filters were likely to be unique.
- 14:47:01 [Norm]
- Jim: If you can't nest, then it makes sense to have them as children.
- 14:47:29 [Norm]
- ...as opposed to having them as an attribute on p:input
- 14:48:09 [Norm]
- Norm: I thought having multiple children would be easier
- 14:48:45 [Norm]
- Jim: I think my resistance as elements is that it makes things three levels deep.
- 14:49:21 [Norm]
- ...I think it would be nicer for users if it could be done with less nesting.
- 14:49:54 [Norm]
- ...In this example, for example, if you had a pipe attribute on p:input, you wouldn't have to have the children.
- 14:50:22 [Norm]
- Norm: I confess, I'd forgotten about the syntactic shortcut of allowing more attributes on p:input
- 14:51:00 [Norm]
- Norm: Maybe we should allow that
- 14:51:33 [Norm]
- Norm: How about p:filter has only a select attribute, only does positive selection, and can be on p:input as a filter attribute as a syntactic shortcut.
- 14:52:16 [Norm]
- Jim: I like that.
- 14:52:26 [Norm]
- Norm: Ok, I'll redraft the proposal that way.
- 14:53:00 [Norm]
- Topic: Any other business?
- 14:53:08 [Norm]
- None heard, we're adjourned.
- 14:53:20 [Zakim]
- -Loren_Cahlander
- 14:53:21 [Zakim]
- -Norm
- 14:53:21 [Zakim]
- -Murray
- 14:53:28 [Zakim]
- -jfuller
- 14:53:29 [Zakim]
- XML_PMWG()10:00AM has ended
- 14:53:29 [Zakim]
- Attendees were Loren_Cahlander, [IPcaller], +1.512.761.aaaa, Norm, +226256aabb, Murray, jfuller
- 16:30:21 [Zakim]
- Zakim has left #xproc