- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 23 Apr 2009 14:12:56 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m27i1bi6hj.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/04/23-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
23 Apr 2009
[2]Agenda
See also: [3]IRC log
Attendees
Present
Richard, Norm, Paul, Mohamed, Henry, Alex
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: telcon 30 Apr 2009?
4. [8]Progress on the default processing model
5. [9]080
6. [10]101: http redirects
7. [11]103: schema questions
8. [12]105: p:exec path separators
9. [13]107: p:exec quote characters
10. [14]108: @href on c:body
11. [15]117: Reconsider non-primary output of p:compare.
12. [16]122: p:choose
13. [17]Any other business?
* [18]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [19]http://www.w3.org/XML/XProc/2009/04/23-agenda
Accepted.
Accept minutes from the previous meeting?
-> [20]http://www.w3.org/XML/XProc/2009/04/16-minutes
Accepted.
Next meeting: telcon 30 Apr 2009?
Vojtech gives regrets.
Progress on the default processing model
Norm looks for volunteers to work on use cases and requirements.
Richard: In XML Core yesterday, when we were talking about when xml:id
processing occurs, that's the sort of thing that I thought this model
might help us describe.
Paul: So things like when XInclude processing occurs by default.
Norm: Yes.
Richard: What we've done so far is describing manipulations of infosets.
But there may also be some aspects that occur before the construction of
infosets.
Henry: Roughly speaking, what others have expressed an interest in is a
recursive, namespace based explanation of what the content of an XML
document is.
Richard: If it contains some kind of kind of encryption, then the meaning
is what you get if you look at what's been signed, etc.
Henry: There are two layers, one of the issues is whether they can be
separated. The first is about what documents mean, what is the infoset
that the author of this document expects to be held to?
... We don't have a definition of that anywhere. One way of thinking about
the default processing model is to consider how all the technologies are
involved.
Paul: So, the default processing model would define some default
processing that you do on a document and you end up with an infoset and
that infoset is special. It's the more official or default infoset. And
because that's the more official one, that's the one that establishes
"meaning".
Henry: The relatively neutral term that the TAG uses for this is the
elaborated infoset.
... Murray Maloney raised an objection to GRDDL going forward because it
didn't answer the question of whether it operated on the pre-XIncluded
document or the post-XIncluded document.
... One way to think about this is that defining the elaborated infoset
would allow specs to say, other things being equal, start here.
<scribe> ACTION: Henry to consider requirement and use cases so we can
have a longer discussion of this topic in a couple of weeks. [recorded in
[21]http://www.w3.org/2009/04/23-xproc-minutes.html#action01]
080
Commenter satisfied, closed.
101: http redirects
Norm: I think the spec needs to be elaborated to say more about what/when
you follow redirects.
Richard: Do we need to say it or just refer to the HTTP spec?
Norm: Point I think, but there's still a little work to be done.
... The technical point is that we should relax the MUST on redirects to
SHOULD.
Henry: Bottom line: people are going to be using libraries.
... I have been surprised occasionally by difference in this area.
... I think it would be ok to say SHOULD.
Richard: How likely is it in the case of a redirect that the body will
contain XML?
Norm: Whatever you get, XProc gives you tools to look at it.
Proposal: Change it to SHOULD
Accepted.
103: schema questions
Norm: I'm inclined to skip this this week, until I can do more based on
our discussions last week.
105: p:exec path separators
Norm: Any comments on my implementation of our path separators decisions?
Proposal: Ratify the decisions about path separators.
Accepted.
107: p:exec quote characters
Vojtech: You can use quote characters to quote strings that contain
spaces.
... What the spec says is that you can quote a single quote character by
doubling it.
... But what happens if you put a single quote character in double quotes
and the other way around. Does that work and how do you write it?
... And how are single quotes interpreted in double quotes?
Henry: Is what you meant, roughly, that you can use a mixture of quotes in
the attribute value?
Norm: No.
Vojtech: If I want to pass an argument that contains a space, I have to
quote it, but what if it contains a quote?
Richard: Can I suggest an alternate solution? Add a new attribute that
defines the argument separator character. By default, it's space, but you
can set it to something else.
Vojtech: I think that's much better.
Henry: I like it.
Proposal: Add a new option to identify the argument separator character.
Accepted.
<richard> The shell equivalent is $IFS
Mohamed: How many options do we have now?
Norm: 435.
108: @href on c:body
Norm: I propose not in V1.
Alex: I agree.
Henry: That's what pipelines are for.
Alex: It sounds like a good idea, but not now.
Proposal: Not in V1.
Accepted.
117: Reconsider non-primary output of p:compare.
Norm: I was entirely persuaded by Mohamed's observations.
... Anyone in favor of this change?
Propsal: No.
Accepted.
122: p:choose
Norm summarizes
Richard: You're saying p:error will have a primary output?
Norm: Yes
Richard: So it'll be an error if you leave it unconnected.
Vojtech: No, output ports can pour onto the floor.
Some discussion.
Richard: The spec does say that non-primary output ports can be
unconnected, primary output ports must be connected.
<MoZ> The primary output port of a step must be connected, but other
outputs can remain unconnected. Any documents produced on an unconnected
output port are discarded.
Norm: In the p:error case, if we don't make it primary then it doesn't
satisfy the condition we're trying to achieve in the p:choose case. If you
don't want to bind it, you can put p:sink after it.
Proposal: Add a primary output port to p:error that always produces an
empty sequence.
Mohamed: I don't want to specify the content.
Henry: What difference does it make, it'll never happen. p:error always
throws an error.
Accepted.
Proposal: Change the stated semantics of p:choose (and p:try/p:catch) to
allow whether or not the output of the step is a sequence to be determined
by looking at the subpipelines.
Norm: But can we do this without going back to last call?
Vojtech: It doesn't change the existing semantics. The old version would
still work. This is a superset.
Henry: It's backwards compatible.
... But it's not forwards compatible. In principle, there could be someone
who would object to this even though they approved of the previous
version.
Paul: I would think that since it's not backwards incompatible, it's fine.
Henry: The problem is that it's not just implementor, it's notionally
reviewers.
... Could this cause anyone to change their review?
Mohamed: If we go back to CR we may get even more questions.
Henry: It's not a new feature.
Norm: That's true.
Henry: I think we should move forward, but be up-front about this at the
PR transition call.
Norm: What about the p:choose/p:try proposal?
Accepted.
Any other business?
None heard.
Adjourned.
Summary of Action Items
[NEW] ACTION: Henry to consider requirement and use cases so we can have a
longer discussion of this topic in a couple of weeks. [recorded in
[22]http://www.w3.org/2009/04/23-xproc-minutes.html#action01]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [23]scribe.perl version 1.135 ([24]CVS
log)
$Date: 2009/04/23 18:12:11 $
References
Visible links
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2009/04/23-agenda
3. http://www.w3.org/2009/04/23-xproc-irc
4. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#agenda
5. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item01
6. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item02
7. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item03
8. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item04
9. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item05
10. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item06
11. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item07
12. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item08
13. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item09
14. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item10
15. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item11
16. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item12
17. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#item13
18. http://www.w3.org/XML/XProc/2009/04/23-minutes.html#ActionSummary
19. http://www.w3.org/XML/XProc/2009/04/23-agenda
20. http://www.w3.org/XML/XProc/2009/04/16-minutes
21. http://www.w3.org/2009/04/23-xproc-minutes.html#action01
22. http://www.w3.org/2009/04/23-xproc-minutes.html#action01
23. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
24. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 23 April 2009 18:13:39 UTC