See also: IRC log
-> http://www.w3.org/XML/XProc/2014/10/08-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2014/10/01-minutes
Accepted.
No regrets heard.
Norm runs through the resolutions.
Norm: Anyone have questions, comments, or concerns about the errata or the disposition of those actions?
None heard.
-> https://github.com/xproc/specification/issues/62
-> https://ndw.github.io/specification/langspec/var-types/head/
Alex: I see the 'as' attributes in the syntax.
-> https://ndw.github.io/specification/langspec/var-types/head/diff.html
Alex: We've never laid out the context for this very well.
Norm: Fair enough.
... I've created issue 80 to track this.
Jim: Are we planning to throw an error if the types don't match?
Norm: Yes.
Norm: Any further
discussion?
... I propose to accept the var-types proposal. Any
objections?
<jfuller> +1
None heard.
-> https://github.com/xproc/specification/issues/38
-> https://github.com/xproc/specification/pull/77
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Oct/0000.html
Jim: Basically, things have moved on a little since that email.
Norm: How about I leave this on the agenda for a week. I'll help get the toolchain setup so that we can review the changed spec.
-> https://github.com/xproc/specification/issues/53
Norm: Everytime we talk about this we waffle a bit. Last time we talked about splitting, Liam was concerned. But since he never turns up for our calls...
Alex: What would we do,
exactly?
... There could be a language specification and a second spec
with a vocabulary of steps.
... It requires people to look at multiple specs, but that's
hardly uncommon.
Norm: Yep.
Alex: You could imagine a pipeline implementation that came with no steps. Just your own custom steps.
Norm: One motivation for a separate spec for the vocabulary is so that it can be revised on a different schedule.
Alex: There's lots of stuff we could do tactically if we had a separate spec.
Norm: Is there anyone opposed to separate specs?
None heard.
Norm: Shall we split the XProc
2.0 spec into two specifications: a core language specification
and a step vocabulary specification?
... Anyone in favor?
Jim: I think it's a good idea.
Norm: Any objections.
<alexmilowski> +1
None heard.
Norm: Ok, I'll take a stab at it.
-> https://github.com/xproc/specification/issues/37
<scribe> ACTION: A-252-01 Norm to see if the WG mailing list can be subscribe to the github issue tracker. [recorded in http://www.w3.org/2014/10/08-xproc-minutes.html#action01]
Some discussion of the problems associated with our new github-based tool chain.
Jim and Vojtech argue that this change is confusing wrt the default readable port.
Vojtech: I also think it
conflicts with the input declaration.
... I like the idea of a pipe attribute, which is similar to
the suggestion that we allow an href attribute on p:input.
Alex: There are two separate
things going on, the shortcut for empty and the idea of a
shorthand for referencing other things.
... On the empty side, I wonder how much this has to do with
parameters.
... That's where I've used it a lot and I don't know where else
I've used it.
... The shorthand to refer to other things is a different
usability question.
Norm: I think I'm hearing
consensus *not* to make the change proposed in issue #37.
... Anyone disagree?
... I propose that we reject this request.
... Any disagreement?
None heard.
->http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Oct/0016.html
<Zakim> ht, you wanted to ask about 2.7.8, and other similar bits of the spec
Henry: The new 2.7.8 is
p:make-map()
... I don't think "markup errors are ignored" is
acceptable.
... It occurs to me that we need to perhaps be more explicit
about this. We might need to think about giving a general
purpose option between strict and lax.
... Where what I have in mind is that the default behavior is
we'll ignore individual parameter bindings that we can't make
sense of but if we can find ones we can make sense of we'll use
those.
... I think we have to be clear that it has to be a
document.
... If it's not clear how to make sense of it, you have to halt
and catch fire. And there should be an option to specify that
behavior if the document isn't valid.
... I wonder if there are other things like this that we need
to treat in a more-or-less uniform manner.
<ht> By 'like this', I mean little XML languages in the c: namespace
None heard.