See also: IRC log
Norm: The substance was PSVI support which I think we sorted as best we can before a new draft.
Henry: My action is still
outstanding, but I don't think that should get in the
... To look for things that point outside the subtree.
Regrets from Paul.
Norm: We need to decide when
... I think we're just about there, just the PSVI stuff I think.
... Can anyone think of anything we need to deal with first?
Henry: It wouldn't be a bad idea to solicit feedback from our readers.
<scribe> ACTION: Henry to setup an xproc developers list at w3.org [recorded in http://www.w3.org/2008/05/29-xproc-minutes.html#action01]
Murray: The GRDDL WG is finished,
I made a point of ensuring that there was a comment in the
GRDDL spec that pointed to XProc.
... I wonder whether in of this groups work there is an example of an XProc script that takes an XML document and turns it into triples.
Norm: I don't think we have one, but there's nothing to prevent us from creating one.
Alex: Do you have a specific example in mind?
Murray: No, but I think it should be as simple as possible.
Norm: It would be nice if it did more than XSLT.
Murray: All it has to do is some validation and run some RDFy kind of tool over the result.
Alex: Is there an example in the GRDDL spec?
Murray: Yes, there are a few.
Norm: There's certainly room for
more examples in the spec, and that would be a good one.
... So, coming back to last call.
... I was thinking along these lines: LC mid June, CR late July, PR in mid September?
Mohamed: Today we can have select
on p:input, which is static.
... I have some use cases where I need to pass an XPath expression to a step where the expression is constructed by the pipeline.
...p: load is symmetric with p:document, it would be nice to have p:filter symetric to select on input.
Norm: And this is a select expression not a match because if you wanted a match you'd just use split-sequence and ignore the non-matched parts.
Henry: I'm confused. In what sense is p:input static, if I had an expression in a variable why wouldn't that work?
<ht> HST: What is wrong with <p:input select="$foo"/>
Mohamed: That gives you the string of $foo, but doesn't use it to select parts of the document.
<ht> Right, what you want is, as it were, <p:input><p:option name="select" value="$foo"/></p:input>
Richard: $foo is a string which
isn't a node set so it's an error.
... We don't require the node set to come from the document, which is a little surprising.
Murray: So $foo in an argument should be evaluated to what it is.
Richard: The select expression si
$foo, and its value is teh value of $foo and it must be a
... And that's an error.
Some discussion of the meaning of evaulated select expressions.
Henry: We could make select into an option.
Norm: I think that would be really confusing.
<richard> we could just add a function to our xpath extensions, like exslt's dyn:evaluate
Mohamed: The only thing that
bothers me about that is, what's the context of the
... I think the simplest, most compatible thing is to add p:filter.
Murray: In a bourne shell, you can put something you want evaluated inside single quotes.
Murray: I wonder whether a simple syntax solution would be a result.
Proposal: add p:filter as Mohamed suggests
Richard: Required or optional?
Mohamed: p:load is required, right?
... I think this is small enough and providing fairly core functionality, I'd make it required.
Norm attempts to summarize the hash changes.
Mohamed: It's an optional step,
so we can make it a bit stronger. For security reasons, sha1
and md5 are on the way out.
... Security considerations will require more options.
... And it's also valuable to provide crc even though it's not secure, it's widely used.
Norm: I'm sympathetic because I had reservations about the particularly narrow slice I made when I first proposed p:hash.
Proposal: change p:hash along the lines suggested by Mohamed
Norm: Mohamed proposoes a c14n step, we could also do it on serialization.
Henry: C14N specifies what a
string looks like.
... It seems like we'd need this on the serialization options.
... Otherwise you can't output a C14N string form an XProc processor.
... You could have p:c14n, but it would be too limiting.
<scribe> ACTION: Mohamed to propose serialization changes to support C14N. [recorded in http://www.w3.org/2008/05/29-xproc-minutes.html#action02]
Norm: We need to say something about id(), key() the namespace axis, etc.
Richard: key() is added by
... The namespace axis isn't a problem for XPath 1 processors because they must implement it.
... The other things are the functions added by XSLT.
Norm: On further consideration, I think id() is probably ok
Richard: I would have thought that none of these things would be expected to work.
Norm: Well, match patterns come from XSLT, so you might expect them to work there
<scribe> ACTION: Norm to investigate the functions added by XSLT and draft some prose for the spec [recorded in http://www.w3.org/2008/05/29-xproc-minutes.html#action03]
Proposed: add a limit option to p:count along the lines Mohamed suggested