See also: IRC log
Thanks, Zakim, I appreciate the way you hung up on me there.
Date: 3 Dec 2014
<scribe> Meeting: 260
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2014/12/03-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2014/11/26-minutes
Accepted.
Proposed: 10 December 2014 does anyone have to give regrets?
No regrets heard; Norm observes he'll just be back from vacation.
It appears A-252-01, A-256-01, and A-258-02 are completed.
Norm explains the new drafts. No technical changes, just pubrules cleanup.
Norm asks Alex about the high order bit on his reviews.
<jfuller> can the heavy breather mute ;)
Alex: A summary of what has changed is needed.
Norm: Yeah, that's fair. We have
a change log but it's not been well maintained.
... With a changelog and an attempt to address some of the
editorial issues, would that be enough?
Alex: Yes. But it would be good
to do as much as we can.
... We should also add a "this is a work in progress"
statement.
<jfuller> +1 to Alex suggestion 'to work in progress'
Jim: I'm still working my way through them, but I haven't seen anything controversial yet.
Norm: I'm not sure we can make 8
Dec, I might change them to 15 Dec, which is the last Tuesday
before the publishing moratorium.
... We need director's approval for the short names, etc.
... Proposed: Publish these drafts as our FWPD. Editor will
attempt to make editorial improvements as suggested in email
and publish them today. If no objections are raised, they'll be
published as presented.
No objections heard.
Accepted.
<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0008.html
Jim summarizes the email thread.
Jim: Some positive reaction, some detailed syntax discussions.
Norm: Liam expressed some concern about microsyntaxes but I don't see where that wound up in the archives.
<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0012.html
Jim: Vojtech had an interesting twist, but he's not on the call today.
<Zakim> ht, you wanted to say "yes but"
Henry: Yes, but...my first
reaction was positive and my second with my sort of
URI-semantics-worrier hat on was sort of negative.
... What would make sense would be to put a hash in front of
the step name. So if we said pipe="#step1" it would make sense
to view the step name as a name.
... In which case fragids should reference the names. This
suggests that what we really ought to do is treat the step name
as a part of the URI so that we can use the fragid to identify
the port.
... But that's a little tricky, because then we're saying the
base URI for interpreting this attribute is not the URI of the
document, but is the URI of the document ending with a
slash.
... So that we can then resolve another step in the path
correctly to get us to the step and then use the fragid to get
us to the port.
Norm: Step names aren't unique; you can find the right one "from the bottom" but not "from the top".
Henry: The URI syntax is its strength and its weakness, it invokes a set of conditions that we don't satisfy.
Jim: I thought we could just make up any id syntax we wanted.
Henry: Yes, we could do that.
Jim: Is it worth bending over backwards to get the URI syntax to work?
Henry: I wasn't trying to do that, I was just trying to leverage the analogy. I think attempting to unify pipe with document is a bridge too far.
Norm: I also worry that it would encourage people to imagine they could do strange things like point into steps in other pipelines.
Jim: Yes, there are syntactic
issues.
... The port@mystep variation is interesting. I think people
like it.
... That sort of emaily form is fundamentally ambiguous.
Norm: How is that ambiguous?
<ht> I could live with it, but I ( and I think Vojtech also) prefer the other order
Jim: It's not a microsyntax that's defined anywhere else, so users won't have any preconceived expectations.
<ht> I really don't want to view this as a URI at all
Norm: I agree with Henry; I'm not opposed to a URI if it makes us all warm and fuzzy, but it isn't a goal.
<ht> My reason for the order is that that works better with defaulting to the primary output port
Norm: Stepping back just a bit, I'd like to make sure we have continuity over all our shortcuts before we start trying to put them in the spec.
<ht> I.e. xxx defaults to xxx?result, rather than result?xxx (for some value of ?)
Jim: I hear what you're saying.
Norm: Maybe proposals for syntactic shortcuts could go on the comments for the issue about syntactic shortcuts.
<ht> +1
<scribe> ACTION: A-260-01 Jim to add the from proposal as a comment on the syntactic shortcuts issue [recorded in http://www.w3.org/2014/12/03-xproc-minutes.html#action01]
Norm: And I'm not saying that has to be today.
<ht> two options wrt appearance of from|pipe attr _and_ p:pipe child. . . -- replace, or (ap|pre)pend
<ht> I guess that's three options
Norm: I wonder about how @from (or @pipe or @whatever) interacts with a child p:pipe element.
<ht> I like error
Norm: I think it would have to be an error if we don't allow both.
Norm worries about what happens when people want to put other sorts of bindings in the attribute value.
Jim: I think Henry didn't like the name @pipe.
Henry: I'm tentatively persuaded
by your reply; I'll sit on it a bit longer and see how I feel
when I see more examples.
... I'm still slightly unhappy about the lack of directionality
which with hindsight I should have felt for p:pipe as well. But
it seems worse in the attribute.
... Write it up as @pipe and I'll think about it some more.
Jim: I'm not strongly attached to one or the other.
<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0010.html
Jim: I had some IRC conversations
about it, but there hasn't been any email replies.
... What would the binding be for the variable's select
expression.
Norm: I think it has to be the default readable port for the step in which it occurs.
Jim: As we consider syntax, this doesn't have as big an impact as the pipe one. It does fix the ugly p:group idiom.
<ht> It encourages good software engineering practice
Norm: I think it was well received last week.
<ht> I.e. give things names, don't re-write expressions
Jim: The next step would be how awkward is it to refer to the variable when you're using the shortcut syntax on the step itself.
Norm repeats Henry's arguments against from last week. Henry recants.
Henry: I think it should be an
error to refer to such a variable. Either of the other ways
will result in confusion for someone.
... If it's not an error then folks who think of the shortcuts
work like nested p:with-options, they'll think it should work
one way, and folks just reading the pipeline will think it
should work the other way.
... I think folks using nested p:variables are reasonable
sophisticated. We should ask for feedback and if there's
conflicting results, we'll have to make it an error.
<jfuller> completely agree,
<jfuller> my call dropped, coming back
Norm: I think error makes good sense, that hadn't occurred to me.
Norm considers the implementation details and shudders a bit.
<jfuller> back
<scribe> ACTION: A-260-02 Jim to put the proposal in a new issue for the spec. [recorded in http://www.w3.org/2014/12/03-xproc-minutes.html#action02]
Norm: We're still thinking about a f2f in Europe in June but it's too early to schedule.
Henry: The other possibility would be east coast of the US in August when I'll be coming through.
<ht> +1 to Japan (or Marrakech)
Adjourned.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/make up any/make up any id/ Succeeded: s/it's strength/its strength/ Succeeded: s/we people/when people/ Succeeded: s/Two options/two options wrt appearance of from|pipe attr _and_ p:pipe child. . ./ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Loren Jim Alex Norm Henry Agenda: http://www.w3.org/XML/XProc/2014/12/03-agenda Found Date: 03 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/03-xproc-minutes.html People with action items: a-260-01 a-260-02 jim[End of scribe.perl diagnostic output]