See also: IRC log
-> http://www.w3.org/XML/XProc/2013/03/13-agenda
Alex proposes to discuss the Processor Profiles document.
Jim has some feedback on XProc from a group of students.
Accepted with those changes.
-> http://www.w3.org/XML/XProc/2013/02/20-minutes
Accepted.
No regrets heard
A-217-01: Completed
A-217-02: Completed
A-219-01: Completed
Norm: Anything to say, Jim?
Jim: No progress so far.
Alex: There's one outstanding action item, the DSDL one.
Norm: I've put that in the actions file for next time. Not sure if I've done that.
Alex: I think we could call 5.8 out of scope.
Alex: It's about the processing
model, it's not really about pipelines.
... It's about things we didn't do in the processing model
document.
Norm: I'm ok with dropping it.
Alex: And 5.26 is a V.next feature. So that leaves us with 2 left over.
<jfuller> tiny wisps of smoke emitting from the back of my mobile phone ... now that cant be good
<jfuller> battery well and trully gone
<jfuller> seeing if I can run with adaptor only
<jfuller> brb somehow
Alex: 5.20 and 5.24 are the same
thing and 5.25 is probably doable.
... And we have Norm's action for the other one.
Norm: So we're in good shape for V 1.0 use cases.
Alex: I think so, we need to
document the new stuff. We have one for non-XML documents, I
did the epub and dsig steps.
... We should collect some more
... My idea is that we put a table in the document with
pointers to all the V1.0 use cases that I collected in email.
Then if there was significant discussion, that we record those
things in the use case document.
Norm: I think that's a perfect plan.
<scribe> ACTION: A-228-01 Jim to incorporate such a table into the new Use Cases and Requirements document. [recorded in http://www.w3.org/2013/03/13-xproc-minutes.html#action01]
Norm: I don't think Jim has made
any progress and his phone has died so...
... Alex, you observed that we should make sure the steps can
do EPUB, which I think is true.
Alex: I think we should publish a use case that documents those two requirements.
<scribe> ACTION: A-228-02 Norm to send email documenting the EPUB requirements on a ZIP step. [recorded in http://www.w3.org/2013/03/13-xproc-minutes.html#action02]
<jfuller> no results on any of my actions
Alex: For ZIP and DSIG these are going to be Notes, right?
<jfuller> yes notes is how I am doing ZIP/UNZIP
Norm: Right, at least in the short term, Notes are the cheap and cheerful way to publish them.
Alex: I think we should go back to Murray's document and see if there are useful bits we put in there.
Norm: Sure.
Alex: I sent out a catagorization of all the extension steps that I found.
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Feb/0011.html
Alex: I wonder if we should look at those
Norm: I'm happy to do some notes.
Alex: Let's look at that list and
see if we can pick out the high priority ones.
... I can give my opinions.
Norm: I'll do the same.
Norm: We've got a bunch of bugs now and I wonder if we want to think about how to attack these.
Alex; We should address these and decide how we're going to fix them.
Norm: For the bugs on the 1.0 spec, I think they'll turn into errata.
Norm: I'll sort them and put them on the agenda; we can plan to do a few every week. Some of them are quite detailed and would benefit from review prior to the call.
<scribe> ACTION: A-228-03 Norm to ask the submitter if any of them are higher priority that others [recorded in http://www.w3.org/2013/03/13-xproc-minutes.html#action03]
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20995
Alex: Ooh, the dtd-validate is ugly.
Norm: I think we want document-uri to be set by p:load
Alex: We have the issue that
documents with the same URI are just not the same
document.
... I also think we need to clarify the scope of evaluation for
an expression like this. We should try to make it true by
narrowing the scope.
Henry asks about dtd-validation. Norm proposes <doc> vs. <doc defattr="value"> example.
Henry: But we spent a lot of time getting to the decision that we did not want to impose the XQuery/XSLT constraint that documents be immutable.
Norm: A narrow reading of the XPath spec suggests that this is only true of documents returned by the fn:collection() function.
Henry: We need to investigate
that, if it's true then we need to add a note to 1.0 saying
that you might think XPath doesn't allow us to do this but it
does.
... For 1.1, I think the question is still on the table. What I
would say, and I'm not sure how this plays with fn:doc. Looking
at XPath, I'm not sure it makes sense to get the same node. And
if it's the same document, how is "same" defined.
... I understood the XQuery/XSLT constraint to mean that you
only got the document once. The fact that you built to
different data models from it is a separate question.
Norm: We should consider the
semantics of the XQuery validate expression
... The p:xslt step lets you control the default collection, so
I think even in a narrow reading you could write a pipeline
that validates this constraint.
Alex: You can definitely have two different documents with the same URI.
Henry: There is the presumption of no-change, steps that don't have to change properties shouldn't.
Some discussion of the last paragraph about p:identity
Alex: If you reference a document with p:document and then p:load, they get the same base URI and they're just different.
Norm: I think we have to say that the document changes in the pipeline, that's what the pipeline is for.
Alex: In the context of a single
expression, the document should be stable.
... Just in one with-option expression.
... Whether or not fn:doc should work is a whole different
question.
... If that's not clear, then we need to make that clear.
<Zakim> ht, you wanted to challenge Norm's statement about document-uri
Henry: I'm not immediately
convinced that we need to say anything about document-uri
... In an XPath 1.0 implementation, the document-uri doesn't
even exist. I don't even know what the distinction is between
the base-uri of the root of the document and the
document-uri.
... So it's not entirely clear to me that we have to say
something about document-uri.
<ht> "Except where the semantics of a step explicitly require changes, processors are required to preserve the information in the documents and fragments they manipulate. In particular, the information corresponding to the [Infoset] properties [attributes], [base URI], [children], [local name], [namespace name], [normalized value], [owner], and [parent] must be preserved."
Alex: I think using fn:doc() in an expression in, for example, p:with-option may be an open issue. What does that mean?
<ht> So, yes, maybe we need an [implicit-]XDM-construction section
Norm: In V.next, we're going to be XDM specific so we may have to deal with the document-uri question.
Henry: My feeling is we've had
part of this conversation before. This is why we have to be
very careful if we do anything with a "resource manager" to be
clear about whether or not pipeline authors can know the URIs
of documents in the manager.
... It would be impossible to do the dependency tracking if you
weren't careful.
<jfuller_> gives up ... going to phone shop ...
Alex: Should p:document href=foo.xml and fn:doc('foo.xml') return the same document? It's only load that could do something different.
Henry: I don't want to go there.
I don't want to get to the point where if I write a stylesheet
which consists entirely of a template that matches / and
returns fn:doc() with a URI.
... We don't want to say that the document returned by that
stylesheet is the same as any other document we loaded. We
don't want to get in bed with the XQuery/XSLT consistency
story.
... In a single *expression* if you use fn:doc() twice with the
same string, then you're in the scope of the XPath
gaurantee.
... I think it's reasonable to discuss if we want to give a
gaurantee with a larger scope. For example, "one byte sequence
was parsed" for that URI in the same pipeline.
Further discussion of caches and such
<scribe> ACTION: A-228-03 Norm to ask the commenter about the last paragraph of bug 20995 [recorded in http://www.w3.org/2013/03/13-xproc-minutes.html#action04]
Further discussion of this bug will be necessary
None heard.
Adjourned