-> http://www.w3.org/XML/XProc/2008/07/31-agenda
Accepted
-> http://www.w3.org/XML/XProc/2008/07/17-minutes
Accepted.
Norm: Skip it, we'll take it to email
Alex gives regrets
Norm: Any comments on my draft of two weeks ago?
Mohamed: I made some small comments that don't seem to be addressed.
Norm: I thought I did them all, but I'll investigate.
Alex: I'm looking at p:file
... p:file is an awful name
Norm: Yeah. Ok, what's better?
Alex: I think p:resource is better
Norm: Ok.
Alex: If you point to a resource and it returns an XML media type.
... Does it get escaped?
Norm: Yes, it does. But maybe that should be made more clear.
Mohamed: How about p:unparsed-text?
Alex: But binaries do get parsed
Mohamed: How about p:data?
Norm: Anyone who can't live with data?
... Ok, let's float that one for the next draft and see what happens.
Mohamed: You didn't put the content-type attribute in the examples
Norm: Oops.
Alex: We also need to change the name of the wrapper.
... If we return a default, then it's content-type without a namespace. If it's in your namespace then we can put content-type in the c: namespace
Norm: I'm happy with that.
<scribe> ACTION: Norm to change p:/c:file to p:/c:data and make the content-type attribute appear in the c: namespace if a non-c:* wrapper is used.
Norm: Let's not.
Alex: Not in V1 works for me.
Mohamed: Me too.
Vojtech: I agree.
Norm: I propose to take it out of the next draft.
Alex: What are we losing?
Norm: You won't be able to write XPath expressions in your pipeline that refer to schema datatypes other than the builtin/predefined ones.
... You won't be able to refer to "x:hatsize".
Alex: I don't think it will hurt us to wait until V.next
... If we do it now, we could paint ourselves into a corner.
<scribe> ACTION: Norm to remove p:schema-import.
Norm expresses his misgivings.
Alex: Nope, I don't think it's unreasonable to expect implementors to be able to change the dynamic context.
Norm: Ok, I'm content.
Alex: But shouldn't they be consistent?
Mohamed: I think for label-elements we used $p:index instead of position() because we didn't need last() at all.
... For split-sequence, we do need last sometimes.
Norm: Right, so we'd need $p:last.
Mohamed: I think the way it is is consistent.
Norm: I don't hear any motivation to make this change.
<scribe> ACTION: Norm to clarify that position() and last() are expected to work in p:split-sequence
Norm: I think the current situation is a bit odd, shouldn't we make it an error to specify both a prefix and a namespace?
Alex: yes
Mohamed: Can we give an exception if the namespace binding for the prefix is the same as the URI?
Norm: I'm ok with that.
Mohamed: I thought the point of using a prefix and a URI was to *request* that binding.
Scribe struggles to keep track of the thread
Vojtech: If you're reading parameters from a file, then you might use QNames, but if you're generating them then you can use the namespace attribute and use NCNames in names.
Mohamed: The attribute namespace appears only on c:param.
Norm: Right. So this is only about c:param.
Mohamed: So I thought that this was for establishing that binding.
Norm: I don't think the prefix is *ever* relevant on parameter names, they're only used by the implementation.
Alex: The bug is the namespace consistency problem; the answer is just to say they have to match.
Norm: We're running out of time, is anyone uncomfortable with adopting at least a temporary resolution that says they have to be consistent.
Accepted.
Mohamed: Could Vojtech provide an example where it's troubling to not use @namespace.
Vojtech: If you want to generate a c:param in XProc, then you'd have to be able to create an xmlns: declaration.
Mohamed: Could you send it in email?
Vojtech: Sure.
Face to face?
Norm: We're planning to meet at the technical plenary
... Who's going?
Mohamed: I'm going.
Alex: I'll try to.
Norm: I'm going.
... With luck, we'll be able to go to Last Call next week.
<scribe> ACTION: Norm to send mail to the WG about the plenary (including dates of our meeting)
No other business heard