See also: IRC log
<jfuller> note I've updated home page http://www.w3.org/XML/Processing/
<jfuller> (added link to date2type xproc ref)
+ discussion of the zip/unzip step: http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html
No regrets heard.
Jim: Are we going to have a
policy on namespaces in notes?
... In the p:template note, we put the steps in the standard XProc namespace.
... Are we going to follow that convention?
Norm: I think we can put the steps we publish as W3C Notes in the XProc namespace.
No objections heard.
Jim: There's an open question
about character sets. If you unzip an archive, and you get a
file, what is the charset? Did we agree to amend the c:file
element to include a charset?
... If not, I think we should.
Norm: I think it's a good idea, whether we did or not, I think you can add it in the zip/unzip note.
Jim: On the zip step, we output the zip file at href location.
Norm: I thought the zip file updated a file at the @href location.
Alex: To some extent this depends
on what we do with binaries and the pipeline in V.next.
... You could do what you're doing now, or if we get binary working, you could pass the zip file back.
... How quickly do we want this to be published?
... I have some questions about this relating to EPUB3 and encryption.
... I don't know if we can answer them that quickly.
Jim: I reviewed EPUB3 and I think
this step can do it.
... The missing bit is the signature.
Some discussion of encryption and signatures for EPUB3
Norm: I don't think we have to
rush to publish it.
... There are two levels of encryption, a zip file can contain encrypted or it can contain encrypted items.
Jim: What happens if you have
more documents on the source port than you specify in the
... Is that an error? Do we want to add an option?
Norm: I'd be content with either it's an error or they get ignored.
Some discussion of how to zip files that are sitting on disk.
Some discussion of the src attribute on the zip:entry
Jim observes that it's not finished; he just had some questions.
Jim: If we're going to publish
this before V.next; we'll have to make it work with
... but we can republish it after V.next, right?
Alex: Is there a simple zip that we could put in here that would work today?
Norm rambles about some of the open questions
<jfuller_> I think we can make a 'simple' example of zip that satisfies Alex's concern
Vojtech: The zip step is
different from p:store or p:xsl-formatter; it returns something
... In V.next we might want to return the binary data from those steps as well.
... Maybe we should do the same thing from p:zip, just return a URI that points to the ZIP file.
Norm: I could live with
... We do need a p:zip-manifest step (or an option on p:unzip) that returns the manifest.
Jim: I'm not sure there is an answer.
Alex: I still maintain that it
will be true during the execution of that XPath
... And if it's evaluated later, it'll be true during that expression as well, even if it's different from the first time.
... If I store a document and then later load it, do I get the same document.
Norm: In XSLT, you can't produce two xsl:result-documents with the same URI, but we don't impose that limitation.
Alex: If the execution context is each individual step, then you get the expected results.
<scribe> ACTION: Norm to make this point as a comment in bug 20995. [recorded in http://www.w3.org/2013/03/20-xproc-minutes.html#action01]
<p:pipeline version='1.0' name="pipeline" xmlns:p="http://www.w3.org/ns/xproc"> <p:option name="opt" required="true"/> <p:identity/> </p:pipeline>
Vojtech: For the outer pipeline, this isn't really a static check.
Norm: The outer-most evaluation is certainly special.
Vojtech: In the command-line case, it's certainly on the boundary between the static evaluation phase and the run phase.
Alex: It would be nice to leave
it open to implementors.
... At minimum it should be a dynamic error.
Norm: I don't want to make it a dynamic error.
Vojtech: We could say it's a static error not to pass an option.
Norm: I propose that we remove the word invoke and add a note that says that the top-level execution is a little bit special
<scribe> ACTION: Norm to comment on 21002 with proposed wording. [recorded in http://www.w3.org/2013/03/20-xproc-minutes.html#action02]
Vojtech: We could say that the top level case is conceptually the same as having a pipeline that imports your pipeline and runs it.
Norm: I'm hoping we don't need to go to that level of detail.