See also: IRC log
Alessandro gives regrets.
Norm: This is Vasil asking about environment variables.
Henry: Something needs to be said about environment variables. At the very least, that it's impl defined what environment variables are passed through.
Richard: I don't think so. It
seems to me it depends on the OS how it works and it's a QoI
... Environment variables are an OS-specific concept.
Henry: Can we say that the "environment" (lower case e) is implementation defined.
Richard: I assume that lots of things are implementation defined, like shell expansion in commands.
Norm: I'd have thought not.
Richard: For example, 'C'
specifies that the command is passed to a command
... which in Unix is a shell where expansion does take place.
... we probably should say something about that.
Henry: I think the answer there is 'no', or impl defined.
Richard: We've separated out the
arguments from the command.
... If you want some sort of shell expansion, then you can make the command you run /bin/sh
... or whatever is appropriate.
Norm: I'm tempted to go back to Henry's suggestion and say that the "e"nvironment is OS and implementation defined.
Some discussion of parameters
Accepted. Implementation defined.
Norm: But we're not providing support for envars.
Norm: I think we resolved this last week, all the steps that have normalization parameters are supposed tohave them all. Any variance was a bug.
Norm: I think this is resolved by the changes in 2.9 Security Considerations.
Mohamed: We have to also have a warning about user-defined steps.
Norm: So we need to say that
p:exec can be inside user-defined pipelines
... I suppose we could also say something about user-defined steps that are defined using Java code or something.
Richard: Rui mentions explicitly the case that the p:exec is in an external library.
<scribe> ACTION: Norm to expand 2.9 a bit more to cover these cases. [recorded in http://www.w3.org/2007/12/20-xproc-minutes.html#action01]
Norm: I think this is really
about base URIs, which I'd thought we'd worked through, but now
I'm not so sure.
... It might make sense to augment p:store so that it uses the xml:base value of the document element if it has one.
Some discussion of how doctype declarations established by the serialization in XSLT might come into play.
Henry: I was chasing this the
other day and discovering that Saxon does better than most
other processors about changing the base URI if you add an
... We did say that preserving base URI properties was something you should do, but we didn't directly address this point.
Norm: Toman wants to change the base URI in a specific way.
Richard: What's more, he probably wants it in unabsolutized form.
Norm: Maybe we need to think about this some more...
Richard: The clunky way to fix this is to start with a document that lists the documents rather than directly with the list of documents.
Norm: Should we leave this one open a bit and see what progress we make.
Let's take this one to email.
Richard: The p:for-each step already does some things to the XPath environment, it could put something in which was the URI of the document in question.
Some more discussion of the examples
Richard observes that the select in p:store could access the extension function
<scribe> ACTION: Norm to fix the XProc home page [recorded in http://www.w3.org/2007/12/20-xproc-minutes.html#action02]
Norm: This what extension to use...
Henry: Whatever convention we
establish, people will follow.
... We ought to give a little thought to the extension
... We could just expose them as .xml
... Since we're toying with a media type, web server administrators will be unhappy if we don't pick a suffix.
<ht> allinurl: xpl filetype:xpl
Henry: There are about 8000 pages
that end in .xpl
... Orbeon uses .xpl
Alessandro: works for me!
Henry: So is this the way we're going
Norm: I'm not really fond of the idea of making a statement directly about it in the spec, but I'm happy to use .xpl in examples and the test suite, etc.
Henry: We have an issue about the media type stuff and fragment identifiers. We'll get back to this, indirectly, when we cover that issue.
Norm: I'm happy that we have an informal consensus to use .xpl, but I don't feel like we need to add it to the spec just yet.
Alessandro: The XSLT spec says that most of the stylesheets use the extension .xsl
Norm: Right, in the media type spec, I'm happy to do that too.
Not in V1
Norm: So we get XSLT 2.0 match
patterns if xpath-version=2?
... Anyone disagree and it's just the editor's job to work that out
Richard: What's the difference?
Norm: XSLT 2.0 match patterns can include variable references
Henry: And can have functions in places other than predicates
Some discussion of the features of XSLT 1.0 and XSLT 2.0
<scribe> ACTION: Editor to make it so. [recorded in http://www.w3.org/2007/12/20-xproc-minutes.html#action03]
Happy holidays to all!