See also: IRC log
-> http://www.w3.org/XML/XProc/2007/08/02-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2007/07/26-minutes
Norm thanks Paul for chairing.
Michael gives regrets
-> 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.
-> 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]
-> 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.
-> 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]
-> 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.
Adjourned.