See also: IRC log
-> http://www.w3.org/XML/XProc/2007/05/10-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/05/03-minutes.html
Accepted.
Henry gives regrets
Alex to craft a proposal on serialization, continued
Henry to write up pipeline state variables, completed.
-> 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.
-> 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.
Accepted.
-> 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.
-> 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.
-> 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.
-> 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.
Accepted.
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0099.html
Alex: I'm happy to do it.
Henry: I agree.
Accepted.
<scribe> New public draft in two weeks?
General agreement
<MoZ> ? topic 8
Adjourned.