XML Processing Model WG

Meeting 110, 01 May 2008


See also: IRC log


Norm, Paul, Alex, Mohamed, Henry, Andrew, Richard, Michael [xx:15-]
Rui, Vojtech


Accept this agenda?

-> 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.


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/04/24-minutes


Next meeting: telcon 8 May 2008?

No regrets given.

New public working draft

Was published today!

Update to p:www-form-urlencode

-> 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:variable name="param" select=".">
    <p:pipe step="foo" port="result"/>

  <p:string-replace match="whatever">
    <p:input port="source">
    <p:option name="replace" select="concat(.,$param)"/>

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.

Short form of p:base-uri and p:resolve-uri

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.


Support for other media types in p:unescape-markup

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

Leave until Vojtech can be present.

Where are @psvi-required, @xpath-version, and @ignore-inline-prefixes allowed. And what are the rules for when they are nested?

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?


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.


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.


Any other business?

None heard.


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/05/08 18:40:54 $