- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 08 Apr 2015 21:51:57 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87mw2iqaia.fsf_-_@nwalsh.com>
See http://www.w3.org/XML/XProc/2015/04/01-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 268, 01 Apr 2015
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Jim, Loren, Murray
Regrets
Henry
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Semantics of p:cast-content-type, issue 116? (Continued from
last week, review minutes.)
4. [8]Clarify p:load, issue #145; see proposed changes to
p:document, p:load, and p:http-request.
5. [9]Norm's proposal for filtering inputs, see p:filter.
6. [10]Any other business?
* [11]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [12]http://www.w3.org/XML/XProc/2015/04/01-agenda
Accepted.
Accept minutes from the previous meeting?
-> [13]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.
Semantics of p:cast-content-type, issue 116? (Continued from last week, review
minutes.)
-> [14]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.
Clarify p:load, issue #145; see proposed changes to p:document, p:load, and
p:http-request.
-> [15]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's proposal for filtering inputs, see p:filter.
Norm attempts to summarize
[16]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.
Any other business?
None heard, we're adjourned.
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2015/04/01-agenda
3. http://www.w3.org/2015/04/01-xproc-irc
4. http://www.w3.org/XML/XProc/2015/04/01-minutes#agenda
5. http://www.w3.org/XML/XProc/2015/04/01-minutes#item01
6. http://www.w3.org/XML/XProc/2015/04/01-minutes#item02
7. http://www.w3.org/XML/XProc/2015/04/01-minutes#item03
8. http://www.w3.org/XML/XProc/2015/04/01-minutes#item04
9. http://www.w3.org/XML/XProc/2015/04/01-minutes#item05
10. http://www.w3.org/XML/XProc/2015/04/01-minutes#item06
11. http://www.w3.org/XML/XProc/2015/04/01-minutes#ActionSummary
12. http://www.w3.org/XML/XProc/2015/04/01-agenda
13. http://www.w3.org/XML/XProc/2015/03/25-minutes
14. https://github.com/xproc/specification/issues/116
15. https://github.com/xproc/specification/issues/145
16. https://ndw.github.io/specification/langspec/input-filter/head/xproc20/diff.html#p.filter
Received on Thursday, 9 April 2015 02:52:25 UTC