See also: IRC log
Date: 4 November 2010
<scribe> Meeting: 183
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Henry can call in between 16:15 and 17:00, so we'll move review of processor profiles to the end of the day
No regrets heard.
(We've got things mixed together on the issues list; Norm will fix that later)
Vojtech: It would require all implementations to change.
Alex: It is annoying.
Norm: I don't hear consensus to make the change as an erratum.
Mohamed: I think it's an uncommon
problem, and the folks who encounter it, the ones using
xsl:result-document, are probably able to work around it.
... It might be more confusing for users with simpler stylesheets to understand why it's a sequence.
Proposal: No change to the spec, the test suite has already been updated by Vojtech.
Mohamed: We only say "may" in the spec, so I don't think we can say that xml:id processing is mandatory.
Vojtech: But the revised profiles document makes it explicit.
Mohamed: We don't have xml:id in the implementation-defined features list.
Norm: I think we need to do that
as an erratum.
... I just don't think we can change "may" to "must" in an erratum.
<scribe> ACTION: Norm to draft an erratum to add xml:id to the implementation-defined features list. [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action01]
Alex: If you were going to make
xml:id required, you'd have to say it was performed on all the
inputs where ever they came from, on p:document, on p:inline,
and on the outputs of all steps.
... Should we say that in the spec as part of the erratum, explaining why xml:id was left as "may"?
Norm: Yes, I'll try to do that when I add the text to make xml:id implementation-defined
Proposal: No technical changes, just clarify that xml:id is an implementation-defined feature
Norm: this looks like a straight-up erratum to me
Sounds of general agreement
Proposal: Fix the prose for p:xpath-context to make it clear that err:XD0026 should be raised there too.
<scribe> ACTION: Norm to propose an erratum to fix p:xpath-context [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action02]
(Topic suggested by Mohamed)
General discussion: Tubular submitted test suite results recently. There's a .NET implementation in the works from Oliver H. Vojtech knows of another Java implementation that's coming.
Mohamed: We should update the public XProc page too.
Norm: Yes. Want to take a stab at it?
<scribe> ACTION: Mohamed to propose new text for the public XProc page. [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action03]
Mohamed: You can do it with XSLT
Some exploration of how XSLT Simplified Stylesheets work
Alex: Are some of these things really just syntactic sugar that you could implement by translating to some equivalent 1.0 pipeline?
Norm: What should we do next? Fold up our tents and go home or do more work?
Liam: The XML Activity has a charter, as do the individual working groups. They all expire in January. This is normal, it's a chance for the membership to review activities.
Liam outlines the process.
Some discussion of 1 or 2 year charters; a 2 year charter implying XProc 2.0 work.
Norm: We have two implementations
and reports of as many as four or five more in the works.
... I think I'd like a 1 year charter for maintenance and possible requirements gathering, then after a year see where we are.
Liam: I'd like to be able to
consider pipelines, with synchronization points, as a possible
solution for more complex processing requirements
... For example, as an alternative to XQuery Scripting Extensions.
Norm: I'd be happy with a charter that broadly spoke of maintenance and possible requirements gathering with some explicit discussion of interaction with other working groups to consider possible cooperative activities.
Hello ht! ;-)
<ht> Afternoon norm
<ht> dialing . . .
ugh. want to use skype to a computer instead?
<caribou> can't you get zakim to call you?
<ht> Not team anymore :-(
we can't here you
we can't hear you either
we may end up with skype as the only option. Carine has gone to look for a better phone
<ht> This is weird
<ht> I can hear you guys
<ht> but zakim doesn't know we're here???
<ht> You can re-tell what I type
<ht> I'm very happy with that outcome
<ht> I will help if we can actually figure out a ToC for the proposed additional doc't
Norm: I think we're in good shape. I like the document. I discussed it informally with the TAG over lunch.
<ht> I remain unconvinced that there is a coherent topic short of a PhD thesis in scope
Norm: There's still a desire to
have a document that says more along the lines of "XML
Functions", but it doesn't have to be this document and it
doesn't have to be a normative product of this WG.
... I agreed that I'd work on such a document.
<ht> I did look
<ht> I believe all are closed
<ht> That is 1, 3 (optimistically)
<ht> Yes, it says it's impl defined
<ht> David may not like that
<ht> You are now too far from the mike
Norm: Next steps: clean up the typo, republish as a Last Call with an explicit note that we plan to go directly from LC to PR. Explicitly ask David and Bjorn if they're content with the resolutions.
<scribe> ACTION: Henry to produce such a Last Call draft. [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action04]
<scribe> ACTION: Henry to close the issues on the DoC that we believe are resolved. [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action05]
<scribe> ACTION: Mohamed to write up a proposal for p:iterate (along the lines of xsl:iterate from XSL 2.1) [recorded in http://www.w3.org/2010/11/04-xproc-minutes.html#action06]
Some discussion of the XML Calabash "iterate-to-fixed-point" step.
Alex points out that his use case, combining the entries of a paginated Atom feed into a single feed isn't well-served by this step.
Mohamed suggested that the p:iterate step will provide a way to do the pagination use case easily.
Florent observes that if you have p:iterate you can implement fixed-point iteration with it.
Mohamed: The p:iterate step will iterate over a sequence, but if the fixed-point case is a useful case, then we can probably make that work.
Topics: More future step possibilities
Norm: We can't add new compound steps until V.next, but there are some we could write up as possibilities
<alexmilowski> We decided not to do this in V1
<alexmilowski> Record here: http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jan/0006.html
<alexmilowski> ...but only indirectly
Some discussion of the restriction on where p:variables can appear. We successfully convinced ourselves that we needed the restriction :-)
Some discussion of dependencies
It might be nice to have a partition element that simply ensures that all of the steps in one partition run before/after all the ones in another partition
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/lien/line/ Succeeded: s/is scope/in scope/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm WARNING: Replacing previous Present list. (Old list: Norm, Vojtech, Alex, Forent) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Norm, Vojtech, Alex, Florent Present: Norm Vojtech Alex Florent Moz Carine Henry (on the phone) Regrets: Henry Paul Jeni Agenda: http://www.w3.org/XML/XProc/2010/11/04-05-agenda Found Date: 04 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/04-xproc-minutes.html People with action items: henry mohamed norm[End of scribe.perl diagnostic output]