- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 02 Aug 2007 12:24:32 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87vebx3nwf.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/02-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 78, 2 Aug 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Paul, Mohamed, Norm, Alessandro, Richard, Michael
Regrets
Henry
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 9 August 2007
4. Question about position/size in loops
5. Proposal to add p:directory-list
6. Proposal to default step and port
7. Proposal to add p:generate-simple-document and p:set-attribute.
8. Proposal to add p:pack
9. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/08/02-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/07/26-minutes
Norm thanks Paul for chairing.
Next meeting: telcon 9 August 2007
Michael gives regrets
Question about position/size in loops
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0035.html
Norm explains his confusion.
Richard agrees it seems confusing.
Norm: I propose that we add an extension function for iteration-size in
for-each and viewport.
... Simultaneously, I'd like to suggest renaming them to
iteration-position and iteration-size.
<alexmilowski> +1 to that
Accepted.
Proposal to add p:directory-list
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0007.html
Norm wonders if his revised proposal addresses the concerns raised last
week.
Alex: I had security concerns.
Norm: I attempted to address that by saying the step could raise a dynamic
error.
Alex: I also wanted the results to be given as a URI relative to the base
URI.
... What I want is to be able to pass the output of this to XSLT and be
able to take the href and the right thing will happen.
Norm: I made the paths absolute so it wouldn't be an issue.
Alex explains how he wants relative URIs to some base.
Norm expresses concerns about the user having to construct the absolute
path.
<p:document href="/foo/bar/baz"/>
<p:load href="/foo/bar/baz"/>
Some further discussion about file: as the default.
<MoZ> <p:directory-list name="list" path="." filter="*.xml"/>
<MoZ> <p:for-each>
<MoZ> <p:iteration-source select="//c:file"/>
<MoZ> <p:output port="result"/>
<MoZ> <p:load href="{/c:file/@name}"/>
<MoZ> </p:for-each>
Norm concedes that he's wrong.
We don't have AVTs, MoZ!
<MoZ> <p:directory-list name="list" path="." filter="*.xml"/>
<MoZ> <p:for-each>
<MoZ> <p:iteration-source select="//c:file"/>
<MoZ> <p:output port="result"/>
<MoZ> <p:load>
<MoZ> <p:option name="href" select="/c:file/@name"/>
<MoZ> </p:load>
<MoZ> </p:for-each>
Richard: I think we should try to make this work in as many environments
as possible.
... It follows that p:directory-list might not return file: URIs. So it
should always put the file: on the front.
Norm: Let's consider the proposal as amended to say that the path names
are absolute URIs. Usually file: but not necessarily.
Richard: I can imagine both absolute and relative URIs being useful.
Norm: I propose then that c:directory set xml:base and provide both path
and filename. One absolute, one relative.
Mohamed asks about the absoluteize step.
Norm agrees we could do that.
Richard: I propose that the 'path' attribute be spelled 'uri'.
... And for the recursive case?
Norm: I don't know what to do about symbolic links.
Richard: I don't think we should do anything about symbolic links.
Norm: So you want to treat them as files, not directories.
Richard: I think this thing should not follow any symbolic links.
Norm: I'm perfectly happy to say that what happens if you have a loop in
the directory structure is implementation-dependent.
More discussion of symbolic links
Richard: Perhaps we should have an "other" element that identifies things
that are neither files nor directories, with some sort of a detail
attribute.
... Do we have a use case for the recursive version?
Norm: We could leave the recursive option out for V1. Wouldn't bother me.
Mohamed: Can we change the semantics, maybe we don't need a recursive
option; just something that can go to any number of levels.
Norm: We could have a 'depth' option instead of a 'recursive' option.
Alex: We decided not to support prev/next in Atom in V1, I think we should
drop recursion, it's very similar.
Norm: Yes, I agree. So let's leave recursion and depth out for at least
the first draft in which this appears and see what users say.
Richard: I'd be happy with that. There's still the possibility of file
systems having things aren't either files or directories.
Norm: I suggest we allow c:other and let implementors use extension
attributes to specify what it is.
<scribe> ACTION: Alex to write up p:directory-list for the next draft.
[recorded in http://www.w3.org/2007/08/02-xproc-minutes.html#action01[8]]
Proposal to default step and port
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0009.html
Norm: I don't think there's much more to be said beyond what I wrote in
the email.
Alessandro: I don't feel strongly, but I think we should limit the number
of syntactic shortcuts we provide.
<alexmilowski> I'm ok with this proposal.
Mohamed: I think this one is valuable because it means you don't have to
name some steps.
... But I think we need to make sure there are no ambiguous cases.
Norm: I don't think there are any ambiguities.
Richard: I think we shouldn't bother, I think there are only a small
number of cases where it would be useful.
Norm: I detect consensus to not add this feature.
Resolved: No change, we will not adopt this feature.
Proposal to add p:generate-simple-document and p:set-attribute.
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0017.html
Mohamed: A lot of components that we have take as inputs documents.
(All of them, no?)
Mohamed: Consider insert which inserts a whole document. But we can't
construct a document from an option.
... I think we need an easy way to construct a document from an option or
parameter.
Alex: Can't you use a parameter and select the value of the option.
Mohamed: Yes, you can go that way, but you can't go the other way.
Alex: I can set a parameter from an option value; and then I can use the
p:parameters step to output that as a document.
Norm: Hey, that's right. p:generate-simple-document is a funky alias for
p:parameters.
Alex: To add attribute, I'd need two steps: I'd have to take the option,
put it into a parameter, then run it through XSLT to generate the right
kind of document for p:set-attributes.
Richard: How much of this can easily be done with XSLT and literal
stylesheets?
Alex: I think generate-simple-document is easy, but add-attribute would
require a couple of steps.
Norm: add-attribute does seem like a natural parallel to set-attributes
Some discussion of how they differ
Alex: Set-attributes takes all its options from documents; add-attribute
would take it directly as parameters.
Norm: So add-attribute is just a shortcut for the
parameter/xslt/set-attribute combination.
Richard: if the only distinction is where the values come from, I don't
like the names.
Mohamed: Where are we going to stop inventing atomic components?
... I found lots of use cases where I needed to add or change an
attribute, but not many use cases where I needed to set whole groups.
Norm: We're going to stop when we have consensus to stop.
... We don't have any hard-and-fast rules.
Alex: The set-attributes use cases is the streaming navigation use case
from our Use Case/Requirements document.
Norm: The fact that add-attribute can only set one attribute is what
bothers me.
Richard: I think it's quite common. I am concerned about adding random
functions as we think of them; it would be nice if we could have a more
principled approach.
Yes, implementors can certainly do it.
Richard: I think we'll get more input when we get to last call.
Alex: I'm inclined to wait and see if users find set-attributes too heavy.
Straw poll: Add p:add-attribute or not.
Seven "Yes" votes and "1" absention.
<scribe> ACTION: Alex to add p:add-attribute. [recorded in
http://www.w3.org/2007/08/02-xproc-minutes.html#action02[11]]
Proposal to add p:pack
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/thread.html
Mohamed explains the idea behind p:pack
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0011.html
Richard: This takes a number of ports, each of which has a sequence on it.
Norm: Ouch; we don't have port="*" anymore
Mohamed: I think it would be ok if the step could just take two sequences.
Norm: If you only have two of them, you can do it with p:for-each.
Norm notices that we've run out of time. I suggest we discuss this in
email and return to it next week.
Any other business?
Adjourned.
Summary of Action Items
[NEW] ACTION: Alex to add p:add-attribute. [recorded in
http://www.w3.org/2007/08/02-xproc-minutes.html#action02[14]]
[NEW] ACTION: Alex to write up p:directory-list for the next draft.
[recorded in http://www.w3.org/2007/08/02-xproc-minutes.html#action01[15]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/08/02-agenda
[3] http://www.w3.org/2007/08/02-xproc-irc
[8] http://www.w3.org/2007/08/02-xproc-minutes.html#action01
[11] http://www.w3.org/2007/08/02-xproc-minutes.html#action02
[14] http://www.w3.org/2007/08/02-xproc-minutes.html#action02
[15] http://www.w3.org/2007/08/02-xproc-minutes.html#action01
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[16] version 1.128 (CVS
log[17])
$Date: 2007/08/02 16:23:58 $
Received on Thursday, 2 August 2007 16:24:38 UTC