See also: IRC log
-> http://www.w3.org/XML/XProc/2008/05/01-agenda
Norm's affiliation changes on Monday to Mark Logic, but he anticipates participating as usual, without any changes.
Let's add the items that Mohamed posted if there's time.
Accepted
-> http://www.w3.org/XML/XProc/2008/04/24-minutes
Accepted.
No regrets given.
Was published today!
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0065.html
Mohamed: I think URL encode would
be useful if it could keep the content that is in the element
that matches.
... The content could be, for example, the start of the
URI.
Norm: What would the option contain?
Mohamed: My first idea was an option that says concatentate or not.
Alex: Why not do what we did for generate-id, where we have an XPath expression.
Norm: Ugh. Seems like a lot of complexity for a fairly narrow case.
<ht> So e.g. <p:w-f-e match="href"><p:with-param name="x" value="3"/></p:w-f-e>, with input <action href="http://www.example.org/service?"/>
<ht> would give <action href="http://www.example.org/service?x=3"/>
Mohamed: I don't know if the "?" is in or not.
Norm: It's not.
Henry: Is there an obvious way to
do this otherwise?
... It looks useful and hard to do any other way.
Alex: You can manipulate the parameter port beforehand in any way you want.
Norm: But this is for the GET case.
Alex: Right now you'd have to use
XSLT to combine the two.
... I think we should keep these concerns separate, otherwise
it's a slippery slope.
... We have the match because we do this operation and we have
to put the encoded string somewhere.
... But outside of the scope of perform this algorithm, I'm not
sure that we need to more.
... If that's the case, then we need a better insertion
algorithm.
Mohamed argues about streamability.
Henry: Can we back up one step? I'd like to bring www-form-urldecode into the discussion. I think these ought to be as straightforwardly semetrical as we can make them.
Some discussion of where *decode* is likely to get its input.
Alex: It's there for symmetry. It's a bit of an edge case.
Henry: Then I want parse URL.
Alex: Yes, that would be good.
Norm: You can do what Mohamed wants with url-encode and string-replace
<p:url-form-encode name="foo">
<p:with-param name="foo" select="'bar'"/>
<p:with-param name="bar" select="'baz'"/>
</p:url-form-encode>
<p:group>
<p:variable name="param" select=".">
<p:pipe step="foo" port="result"/>
</p:variable>
<p:string-replace match="whatever">
<p:input port="source">
...
</p:input>
<p:option name="replace" select="concat(.,$param)"/>
</p:string-replace>
</p:group>
Norm: Are you satisfied with that, Mohamed?
Mohamed: Yes, but I think Henry has raised a good question about decoding.
Henry: XPath 2.0 will let you do
it, it'd be very hard with XPath 1.0.
... There's definitely a slippery slope here.
Alex: There's a real need here, but it would be nice to have a URI-handling step that did a good job.
Norm: Stop. We're way off topic, if that's a good idea, someone write a proposal.
<ht> What we're really talking about is microparsing and generating steps, I realise
So we're not changing anything about p:www-form-urlencode.
Norm: For consistency with XPath
2.0, I think we need to leave them.
... we said they'd be exactly the same as the 2.0 functions, so
we shouldn't change them.
Accepted.
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0095.html
Leave until Vojtech can be present.
Proposal: Allow them all on p:pipeline, p:declare-step, and p:library. Also allow ignore-inline-prefixes on p:inline.
Norm: I think a convenience for authors argument could be made for allowing ignore-inline-prefixes in more places, but I'm not going to make it.
Mohamed: I think Jeni's point was that you could group it better if it was allowed anywhere.
Richard: What about nesting?
Norm: We don't say anything yet, that we'll have to decide.
Henry: It's a lexically scoped union, so you can fix it.
Norm: Any comments about where I propose to allow them?
Mohamed: If it's allowed in p:declare-step, it will be allowed for both pipeline and atomic steps.
Norm: Yes, it'll apply to default binding for p:inline.
Some discussion of nesting for @xpath-version
Norm: Everyone content with where I said they could go?
Accepted.
Norm: I think we have a nesting
story for xpath-version
... I think the nesting story for ignore-inline-prefixes is
lexical scope and union.
Accepted.
Henry: I think the semantics of psvi-required should be straightforward: if you don't have an implementation that can do PSVI, it's a dynamic error if you encounter one.
Alex: If you're impl supports PSVI, then every step in your impl is using that API. So having a psvi-required=false doesn't mean you're not going to construct one.
Norm: I think psvi-required=false is either pointless or serves only as documentation.
Some discussion of the semantics.
Alex: The psvi-required error is currently *static*
Norm: I think that's silly, it should be dynamic.
Proposed: Add a new system property that says whether or not PSVIs are being used by this invocation fo this pipeline.
Accpted. Name to be determined by the editor.
Mohamed: I think it would be better if the property just told you whether or not the implmentation *can* do PSVIs.
Richard: What PSVI properties
appear on documents?
... So a p:wrap step will throw out the PSVI properties.
Henry: Right.
Richard: So PSVI properties only arise from the steps that say they can produce them and other steps don't change them.
Henry: I think that's
right.
... Next week we should discuss what sort of preservation we
want.
Propsal: We make the psvi-required error a dynamic error.
Accepted.
None heard.
Adjourned