- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 14 Mar 2013 16:05:20 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2zjy5n14f.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2013/03/13-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 228, 13 Mar 2013
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Alex, Jim, Henry
Regrets
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: 20 Mar 2013?
4. [8]Review of open action items
5. [9]Use cases and requirements
6. [10]Zip and unzip steps
7. [11]Bugzilla spec bugs and use cases
8. [12]Any other business
* [13]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [14]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.
Accept minutes from the previous meeting?
-> [15]http://www.w3.org/XML/XProc/2013/02/20-minutes
Accepted.
Next meeting: 20 Mar 2013?
No regrets heard
Review of open action items
A-217-01: Completed
A-217-02: Completed
A-219-01: Completed
Use cases and requirements
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
[16]http://www.w3.org/2013/03/13-xproc-minutes.html#action01]
Zip and unzip steps
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
[17]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.
->
[18]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.
Bugzilla spec bugs and use cases
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
[19]http://www.w3.org/2013/03/13-xproc-minutes.html#action03]
-> [20]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
[21]http://www.w3.org/2013/03/13-xproc-minutes.html#action04]
Further discussion of this bug will be necessary
Any other business
None heard.
Adjourned
Summary of Action Items
[NEW] ACTION: A-228-01 Jim to incorporate such a table into the new Use
Cases and Requirements document. [recorded in
[22]http://www.w3.org/2013/03/13-xproc-minutes.html#action01]
[NEW] ACTION: A-228-02 Norm to send email documenting the EPUB
requirements on a ZIP step. [recorded in
[23]http://www.w3.org/2013/03/13-xproc-minutes.html#action02]
[NEW] ACTION: A-228-03 Norm to ask the commenter about the last paragraph
of bug 20995 [recorded in
[24]http://www.w3.org/2013/03/13-xproc-minutes.html#action04]
[NEW] ACTION: A-228-03 Norm to ask the submitter if any of them are higher
priority that others [recorded in
[25]http://www.w3.org/2013/03/13-xproc-minutes.html#action03]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [26]scribe.perl version 1.137 ([27]CVS
log)
$Date: 2013-03-14 21:03:45 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2013/03/06-agenda
3. http://www.w3.org/2013/03/13-xproc-irc
4. http://www.w3.org/XML/XProc/2013/03/13-minutes#agenda
5. http://www.w3.org/XML/XProc/2013/03/13-minutes#item01
6. http://www.w3.org/XML/XProc/2013/03/13-minutes#item02
7. http://www.w3.org/XML/XProc/2013/03/13-minutes#item03
8. http://www.w3.org/XML/XProc/2013/03/13-minutes#item04
9. http://www.w3.org/XML/XProc/2013/03/13-minutes#item05
10. http://www.w3.org/XML/XProc/2013/03/13-minutes#item06
11. http://www.w3.org/XML/XProc/2013/03/13-minutes#item07
12. http://www.w3.org/XML/XProc/2013/03/13-minutes#item08
13. http://www.w3.org/XML/XProc/2013/03/13-minutes#ActionSummary
14. http://www.w3.org/XML/XProc/2013/03/13-agenda
15. http://www.w3.org/XML/XProc/2013/02/20-minutes
16. http://www.w3.org/2013/03/13-xproc-minutes.html#action01
17. http://www.w3.org/2013/03/13-xproc-minutes.html#action02
18. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Feb/0011.html
19. http://www.w3.org/2013/03/13-xproc-minutes.html#action03
20. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20995
21. http://www.w3.org/2013/03/13-xproc-minutes.html#action04
22. http://www.w3.org/2013/03/13-xproc-minutes.html#action01
23. http://www.w3.org/2013/03/13-xproc-minutes.html#action02
24. http://www.w3.org/2013/03/13-xproc-minutes.html#action04
25. http://www.w3.org/2013/03/13-xproc-minutes.html#action03
26. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
27. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 14 March 2013 21:05:56 UTC