- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 01 May 2008 12:12:52 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2tzhiovej.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/05/01-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
01 May 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Alex, Mohamed, Henry, Andrew, Richard, Michael
[xx:15-]
Regrets
Rui, Vojtech
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 8 May 2008?
4. New public working draft
5. Update to p:www-form-urlencode
6. Short form of p:base-uri and p:resolve-uri
7. Support for other media types in p:unescape-markup
8. Where are @psvi-required, @xpath-version, and
@ignore-inline-prefixes allowed. And what are the rules for when
they are nested?
9. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
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.
Accepted
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2008/04/24-minutes
Accepted.
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?[7]"/>
<ht> would give <action href="http://www.example.org/service?x=3[8]"/>
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.
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.
Accepted.
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?
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.
Any other business?
None heard.
Adjourned
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2008/05/01-agenda
[3] http://www.w3.org/2008/05/01-xproc-irc
[7] http://www.example.org/service?
[8] http://www.example.org/service?x=3
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[10] version 1.133 (CVS
log[11])
$Date: 2008/05/01 16:11:46 $
Received on Thursday, 1 May 2008 16:13:31 UTC