See also: IRC log
-> http://www.w3.org/XML/XProc/2015/04/01-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2015/03/25-minutes
Accepted.
Proposed: 8 April 2015 does anyone have to give regrets?
No regrets heard.
Reminder: We have a face-to-face scheduled for Edinburgh in June.
-> https://github.com/xproc/specification/issues/116
Norm attempts to summarize
Norm: I think there are two interpretations: it should just change the type without doing anything else.
... or it should (sometimes) do some sort of transformation on the actual data.
... I don't see how the former interpretation can be implemented.
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!
Jim: Is it equivalent to just changing the content type property (document properties)?
Norm: Yes and that's forbidden.
Murray: This is the distinction between casting and coersion, isn't it?
Norm: Yes, basically.
Jim: We could allow the former interpretation by letting the user change the type.
Some review of the current prose in p:cast-content-type
Norm wonders if we should just say it's a binary and it's implementation dependent.
Jim: I think that sounds like an improvement.
Norm: How about I take an action to attempt to improve it and see if we get agreemtn.
ACTION A-268-01: Norm to attempt to clarify p:cast-content-type
Jim: It follows that if we say this step can set the content-type document property, are we going to allow it elsewhere?
... I think we need the step, I'm convinced we don't need to loosen up setting the property independently.
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.
Norm: It has to be something the step knows how to do.
Murray: So that's why you need a coercion step inside a cast step.
Norm: I think the cast step just has to know how to do the coercion.
-> https://github.com/xproc/specification/issues/145
Norm attempts to summarize his drafts.
Jim: I think these are good changes.
... I looked for a spec for filename globbing and didn't find it.
... Should we add an option to p:load to allow recursing through nested directories?
Norm: We could, it feels to me like recursing directories is on the "other side of the line"
Jim: I think it's a simple thing to add
Murray: Being able to list just the files that I want would also be useful.
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
Norm attempts to summarize
https://ndw.github.io/specification/langspec/input-filter/head/xproc20/diff.html#p.filter
Norm: Like filtering in things like ant and gradle, it just simplifies things.
Jim: I think the idea is spot on, but I have some questions about why it's a child of p:input.
... The idea of having multiple p:filters...what does ordering do?
Norm: I removed the interleave problem.
Jim: How about a top-level definition of the filter that you can reuse?
Norm: I sort of thought that the filters were likely to be unique.
Jim: If you can't nest, then it makes sense to have them as children.
... as opposed to having them as an attribute on p:input
Norm: I thought having multiple children would be easier
Jim: I think my resistance as elements is that it makes things three levels deep.
... I think it would be nicer for users if it could be done with less nesting.
... In this example, for example, if you had a pipe attribute on p:input, you wouldn't have to have the children.
Norm: I confess, I'd forgotten about the syntactic shortcut of allowing more attributes on p:input
... Maybe we should allow that
... 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.
Jim: I like that.
Norm: Ok, I'll redraft the proposal that way.
None heard, we're adjourned.