<jfuller> note I've updated home page http://www.w3.org/XML/Processing/

<jfuller> (added link to date2type xproc ref)

Accept this agenda?

-> http://www.w3.org/XML/XProc/2013/03/20-agenda

+ discussion of the zip/unzip step: http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2013/03/13-minutes

Accepted.

Next meeting: 27 Mar 2013?

No regrets heard.

Review of open action items

A-213-14 completed

Use cases and requirements

No progress.

Zip and unzip steps

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 manifest.
... 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 V.next.
... but we can republish it after V.next, right?

Norm: Yes.

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 different.
... 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 that.
... We do need a p:zip-manifest step (or an option on p:unzip) that returns the manifest.

Bug 20995

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20995

Jim: I'm not sure there is an answer.

Alex: I still maintain that it will be true during the execution of that XPath expression.
... 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]

Bug 21002

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21002

<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.

Any other business?

Adjourned.