- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 03 Dec 2014 17:11:09 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87ppc0mir6.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2014/12/03-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
03 Dec 2014
[2]Agenda
See also: [3]IRC log
Attendees
Present
Loren, Jim, Alex, Norm, Henry
Regrets
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting
4. [8]Review of open action items
5. [9]Publication of a FPWD
6. [10]Discussion of the from attribute.
7. [11]Discussion of allowing p:variable within atomic steps
8. [12]Any other business?
* [13]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [14]http://www.w3.org/XML/XProc/2014/12/03-agenda
Accepted.
Accept minutes from the previous meeting?
-> [15]http://www.w3.org/XML/XProc/2014/11/26-minutes
Accepted.
Next meeting
Proposed: 10 December 2014 does anyone have to give regrets?
No regrets heard; Norm observes he'll just be back from vacation.
Review of open action items
It appears A-252-01, A-256-01, and A-258-02 are completed.
Publication of a FPWD
Norm explains the new drafts. No technical changes, just pubrules cleanup.
Norm asks Alex about the high order bit on his reviews.
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.
Discussion of the from attribute.
<jfuller>
[16]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>
[17]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
[18]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.
Discussion of allowing p:variable within atomic steps
<jfuller>
[19]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
[20]http://www.w3.org/2014/12/03-xproc-minutes.html#action02]
Any other business?
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.
Summary of Action Items
[NEW] ACTION: A-260-01 Jim to add the from proposal as a comment on the
syntactic shortcuts issue [recorded in
[21]http://www.w3.org/2014/12/03-xproc-minutes.html#action01]
[NEW] ACTION: A-260-02 Jim to put the proposal in a new issue for the
spec. [recorded in
[22]http://www.w3.org/2014/12/03-xproc-minutes.html#action02]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [23]scribe.perl version 1.140 ([24]CVS
log)
$Date: 2014-12-03 23:04:04 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2014/12/03-agenda
3. http://www.w3.org/2014/12/03-xproc-irc
4. http://www.w3.org/XML/XProc/2014/12/03-minutes#agenda
5. http://www.w3.org/XML/XProc/2014/12/03-minutes#item01
6. http://www.w3.org/XML/XProc/2014/12/03-minutes#item02
7. http://www.w3.org/XML/XProc/2014/12/03-minutes#item03
8. http://www.w3.org/XML/XProc/2014/12/03-minutes#item04
9. http://www.w3.org/XML/XProc/2014/12/03-minutes#item05
10. http://www.w3.org/XML/XProc/2014/12/03-minutes#item06
11. http://www.w3.org/XML/XProc/2014/12/03-minutes#item07
12. http://www.w3.org/XML/XProc/2014/12/03-minutes#item08
13. http://www.w3.org/XML/XProc/2014/12/03-minutes#ActionSummary
14. http://www.w3.org/XML/XProc/2014/12/03-agenda
15. http://www.w3.org/XML/XProc/2014/11/26-minutes
16. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0008.html
17. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0012.html
18. http://www.w3.org/2014/12/03-xproc-minutes.html#action01]
19. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Dec/0010.html
20. http://www.w3.org/2014/12/03-xproc-minutes.html#action02]
21. http://www.w3.org/2014/12/03-xproc-minutes.html#action01
22. http://www.w3.org/2014/12/03-xproc-minutes.html#action02
23. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
24. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 3 December 2014 23:11:48 UTC