See also: IRC log
Date: 08 Oct 2014
<scribe> Meeting: 252
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> 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.
<jfuller> YEHAAA
<ht> Go on, my son!
Norm: Anyone have questions, comments, or concerns about the errata or the disposition of those actions?
None heard.
Issue #62, 2.5.1 Specify types of variables, options, and parameters. See proposal.
-> 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.
<ht> No diff highlighting??
Diff highlighting: follow the link.
-> https://ndw.github.io/specification/langspec/var-types/head/diff.html
<ht> D'oh, sorry
Alex: We've never laid out the context for this very well.
Norm: Fair enough.
... I've created issue 80 to track this.
Alex: No.
Jim: Are we planning to throw an error if the types don't match?
Norm: Yes.
<jfuller> http://www.w3.org/TR/xslt20/
<jfuller> section 2.9
[Definition: Certain errors are classified as type errors. A type error occurs when the value supplied as input to an operation is of the wrong type for that operation, for example when an integer is supplied to an operation that expects a node.] If a type error occurs in an instruction that is actually evaluated, then it must be signaled in the same way as a non-recoverable dynamic error. Alternatively, an implementation may signal a type error during the analys
is phase in the same way as a static error, even if it occurs in part of the stylesheet that is never evaluated, provided it can establish that execution of a particular construct would never succeed.
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: 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.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/None heard// Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Norm Jim Loren Alex Vojtech Agenda: http://www.w3.org/XML/XProc/2014/10/08-agenda Found Date: 08 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/08-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]