XML Processing Model WG

Meeting 67, 10 May 2007


See also: IRC log


Norm, PGrosso, Alex_Milows, richard, Ht, Andrew
Rui, Michael, Mohamed, Alessandro


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/05/10-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/05/03-minutes.html


Next meeting: telcon 17 May 2007

Henry gives regrets

Open action items

Alex to craft a proposal on serialization, continued

Henry to write up pipeline state variables, completed.

Pipeline state variables

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0069.html

Norm: I think there was some confusion about [stepname]_index

Henry: The whole point of for-each is that there's no document sequence, you're getting them one at a time.
... Nonetheless, you may wish to know what iteration you're in.
... Adding functions feels like something that makes me muck with the XPath impl, but adding variables to the context is something I can do from outside.
... There are a bunch of other "environment" variable kinds of things which things like XSLT/XQuery make available: implementation, system, etc.

Norm: There's a function in XSLT: system-property

Paul: I use function-available all the time

Henry: Yes, we might want that

Norm: At the moment, we don't allow references to unknown steps, even behind a condtional.

Alex: It might be nice to say that I use this collection of steps and have a more discernable error.

Any other discussion of Henry's proposal?

Ok. Variables or functions?

Henry: I prefer variables, I think.

Norm: In JAXP API, it's about equally easy.

Richard: Might a processor work in such a way that it doesn't "restart" the evaluation between loops.

Henry: In the very least, the context has to change, so it shouldn't be hard to change variables even then.

Norm: I observe that other specs that extend XPath use functions.

Richard: So far I haven't seen anything that suggests it isn't like a variable.
... I observe that current() in XSLT is a function when presumably that could have been a variable.

Straw poll: Function or variable?

Results: 2 functions, 3 variables, 1 abstain

Henry: I'd be happy to have a note requesting feedback.

Norm: Ok, variables for now with a "priority feedback" note.

Henry's proposal is accepted.

More questions about syntactic sugar

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0143.html

Jeni responded with a much grander proposal involving variables and attribute value templates.

Henry: I sympathize. I'm tempted to go all the way.

Alex: I'm sympathetic to the AVT story as well.

Henry: So href='banana' is the equivalent of name='href' value='banana'
... And href='{xxx}' is equivalent to name='href' select='xxx'
... And you get the probably irrelevant advantage that you don't have to use concat()

Alex: To users, that might be very nice.

Norm: I observe that if we do this, we'll need to say which attributes are AVTs

Henry: My inclination would be to say that we're playing on the edges here. We have no experience with which attributes can be AVTs.

Norm worries about the fact that references to documents will be quite different from an AVT perspective.

Henry: the consequence of that for this story would mean that you couldn't do document references in AVTs.
... For V1 I think we should only allow this for value=
... Giving users choices is bad; so I think I marginally prefer to allow it only on steps
... You can use the super-abbreviated form on step for values that are constant.
... My proposal is: no change to the option element, you can just put the value on the step itself.
... And only there

Norm: Yeah, but it wouldn't work for an option named "name" so maybe we should just ditch the whole thing.

Alex: It doesn't bother me.

Anyone uncomfortable?

Norm: Should we work this up into a draft and see what the public says?

Alex: And it's a static error if you specify the option twice.


Error codes for step errors

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0153.html

Norm: What error do I raise?

Henry: The builtin steps have to say what errors they raise.

Richard: I want it to be possible to use off-the-shelf implementations without having to delve into them to sort out their error returns.
... So I would be in favor of very generic errors that have some kind of detail inside them.

Norm: I'm happy with "step failed" and that's all you get.

Richard: If some steps need more detail then "ok" up to the point.

Alex: The error vocabulary is open so implmentors can add stuff if they want

Norm: Anyone uncomfortable with "there's an error code for step failed"?

Ok, that's what we'll do.

Pipelines that change attributes

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0096.html

Norm: The proposed solution seems odd to me, but clever in its way.

Henry: Maybe we need something that does this, but I don't want to call it viewport

Alex: There's lots of things we can't do. We'll always find new things. I'm not sure that this is worth doing for V1.

Henry: Richard, you have something like this, can you explain it?

Richard: lxreplace is a program that's intended for doing minor replacements on XML documents.
... We've talked before about streaming several of the microcomponents.
... I'm wondering if there's a case here for an extra microcomponent that's like string-replace.
... You have an xpath that can specify attributes or text nodes and it replaces their value with the result of evaluating that expression

Norm: We have that one. Jeni wants to manufacture attributes.

Richard: You could say that this is two separate steps, one that renames attributes and ones that changes strings.

Norm: Look at the example, it's got to construct attributes.

Henry: I think the answer is that we're not ready for this complexity yet.

Norm: Should we postpone this one for a while?

Henry: Yes, I'd say maybe even on the "someday" pile.

Richard: Given that it can be done with XSLT; streaming is just an optimization.

Henry: I still do think that we should consider a not-very-micro component which specializes the standard XSLT design pattern of copying most of a document and changing something about 1 element.
... If/when we come back to this.

Richard: The for-each XSLT component is useful in many cases, but I'm not sure this example is one.

Fixed window use case

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0111.html

Henry: I've found on a number of occasions that it's useful to catagorize things in one step and wrap them in the next.
... With the semantic that they all get wrapped up together.
... We have p:wrap that wraps things; the simple interpretation of what Mohamed wanted is to say there's an optional XPath which you can provide and as long as that value doesn't change, you don't close the wrapper.

Richard: And what happens when things cease to be siblings?

Henry: Then you close the wrapper.
... Ignore comments, ignore PIs, ignore text nodes that contain just whitespace. Otherwise, anytime you hit something that doesn't match the XPath, or doesn't match its value, or isn't a sibling, you close the wrapper.
... My exmaple is the pipeline compiler that needs this; it decorates steps with something about whether or not there's a thread boundary needed. Then you wrap each group of steps in the same thread with a wrapper.

Richard: This is a group component?

Henry: It makes wrap something that can be used as a grouping component

Paul: Mohamed proposed another expression to identify the kinds of things you skip.

Norm: I think you'd still end at non-sibling boundaries

Henry: I don't think that's any harder than what I said.
... It's slightly tricky to write an XPath that detects all whitespace.
... I'd like to think about that a little bit.

<MoZ> text()[string-length(normalize-string(.))=0]

Yes, but that's very expensive.

Norm: Henry's behavior could be the default

Paul: I like that.

Norm: Are we sold?

<scribe> ACTION: Henry to propose wording for the spec. [recorded in http://www.w3.org/2007/05/10-xproc-minutes.html#action01]

<MoZ> do we keep the ignore option ?

Yes, MoZ, I think so.

Empty compound steps

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0120.html

Norm outlines his concerns.

Henry: I think it's not obvious what some of the compound steps mean if they're empty.
... I'm sympathetic.

Paul: It's not a big deal to me.

Norm: I'm not sure we need to have a nop step; you can always use identity.
... Shall we outlaw empty compound steps.

Henry: I'm in favor.


Secondary output on XSLT 1.0 step

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0099.html

Alex: I'm happy to do it.

Henry: I agree.


Any other business

<scribe> New public draft in two weeks?

General agreement

<MoZ> ? topic 8


Summary of Action Items

[NEW] ACTION: Henry to propose wording for the spec. [recorded in http://www.w3.org/2007/05/10-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/05/16 14:12:10 $