XML Processing Model WG

Meeting 179, 26 Aug 2010


See also: IRC log


Paul, Henry, Norm, Vojtech
Mohamed, Alex


Accept this agenda?

-> http://www.w3.org/XML/XProc/2010/08/26-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2010/08/12-minutes


Norm's action is continued. :-(

Next meeting: telcon, 2 September 2010?

Vojtech gives regrets for 2 September.

Propose to cancel 9 September.


Comments on XML processor profiles

Henry: I'd like to talk about whether people think Section 3 is useful.

-> http://www.w3.org/XML/XProc/docs/xml-proc-profiles.html

-> http://www.w3.org/XML/XProc/2010/05/wd-comments/

Norm: I like it. I think it's good to ground our work in the Infoset. I just didn't have a chance to look at the detail.

Henry: I'm happy to let the public help with that.
... I don't like the layout, the "Whether the remaining information item is present is implementation-defined" line is too subtle.
... I think I'd like to say "fix that", fix the other obvious editorial problem wrt the word "ditto", and republish, asking for comments.

Norm: That seems fine to me.

Vojtech: Before we tried to stay away from using infoset terms. I wonder if that's ok, or ...

Henry: I think it is. I don't know what else to do.

Norm: I fear if we don't ground it in the infoset, then it will either not be grounded or we'll have to recapitulate the Infoset.

Vojtech: Does that mean we should use the infoset terms for, for example, base URI, in the profiles?

Henry: I'm not sure, I think we chose that wording very carefully.
... I don't think there's any conflict between the specs.

Norm: I don't think we're obligated to update the language spec based on our terms in this spec.

Henry: Ok. I'll try to have a draft ready in the next 10 days or so.

What's the progression of this document?

Paul: Does this document go through CR? Does it go directly to PR? What do we need to do?

Norm: Good question.
... I guess we need to get the staff contact involved. I'd be a little disappointed if we had to make it a Note, but it wouldn't be the end of the world.

<scribe> ACTION: Norm to touch base with the staff contact to see what they suggest. [recorded in http://www.w3.org/2010/08/26-xproc-minutes.html#action01]

Possible new XProc 1.1 step: p:template

Norm attempts to paraphrase the problem: making it easier to construct fragments of XML from variables and expressions in an XProc pipeline.

Henry encourages us to look at the discussion of Richard Tobin's XML tools functionality near the end of his first message.

Henry: As Vojtech observed, there are two things going on, abbreviating the p:input and interpolation.

Norm: I find the change in the the content model of steps a bit disturbing.

Henry: I also want the variable bindings to be on other ports.

Norm: I think you'll need to stick those in variables.

Henry: The template has to come from a secondary port so that you can write things as I do in the reply to Vojtech.

Vojtech: My problem with the original syntax is that it's not clear how to create elements in the XProc namespace and maybe there would be value in being able to generate the templates dynamically.

Norm: I proposed p:interpolated-inline.

Henry: The problem I have with this is there's no match attribute. There's a fundamental semantic difference, yours takes a document and does what it does with it.
... whereas my proposal uses @match to change everywhere that matches.

Vojtech: How does that differ from putting this in a viewport?

Henry: Maybe it's not, but it's a lot more verbose.
... We're very clear in the document that the only bindings that are visible to step implementations are the option and parameter bindings. And for this to be implemented as a step would require us to break that rule. The curly brace substitution has to be done by the step.

Vojtech: I proposed that we could do it with a parameter input port where you'd pass all these bindings.
... We could add a new attribute to p:inline so that we didn't have to have a different binding.
... Ideally it would be nice if we could make *any* kind of binding dynamic.

Norm: You could give the binding a step and port for interpolation.
... You could say <p:inline dynamic="true" step="mystep" port="result"/>

Norm; Putting it on the binding does make sense to me.

Vojtech: I might want to have two inputs but only have one of them be dynamic.

Norm: To cut the other way entirely, if we allowed AVTs in literal option values, would that be enough?

Vojtech: I think we'd still have the p:string-replace quoting issues.

Henry: It might be a good idea to do that, but I don't think it solves this problem.

Norm: I need to think about this some more.

Vojtech: Yes, there are two parts, enabling templating and deciding what the substitution rules are.

Henry: Right. I don't want to go all the way to the bottom of the slippery slope.
... I think saying that curly braces in literal content (attribute values or text content) is enough.

Vojtech: We could do like p:exec and allow users to specify the quoting characters.

Henry: We're doing just the part of XQuery syntax that does XPath expressions, not full XQuery constructors.

<ht> <elt attr="{concat($a,'}')}"/>

<ht> <elt attr="{concat($a,'}}')}"/>

Some discussion of escaping curly braces.

<Vojtech> So how would I create the following document: <doc>{}</doc> ?

<doc> {{{}}}</doc>

Of course!

Norm: I think that's good progress on the issue.

Any other business?

Norm: I think TPAC registration and hotels are ready for booking.


Summary of Action Items

[NEW] ACTION: Norm to touch base with the staff contact to see what they suggest. [recorded in http://www.w3.org/2010/08/26-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/08/26 15:55:48 $