See also: IRC log
-> http://www.w3.org/XML/XProc/2009/04/23-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2009/04/16-minutes
Accepted.
Vojtech gives regrets.
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 http://www.w3.org/2009/04/23-xproc-minutes.html#action01]
Commenter satisfied, closed.
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.
Norm: I'm inclined to skip this this week, until I can do more based on our discussions last week.
Norm: Any comments on my implementation of our path separators decisions?
Proposal: Ratify the decisions about path separators.
Accepted.
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.
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.
Norm: I was entirely persuaded by
Mohamed's observations.
... Anyone in favor of this change?
Propsal: No.
Accepted.
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.
None heard.
Adjourned.