See also: IRC log
No regrets given.
Skip 25 Dec and 1 Jan; next meeting 8 Jan.
Norm attempts to summarize the thread
Richard: Presumably a sufficiently clever processor can look at the expression and work out if it needs it or not.
Norm summarizes his position.
Vojtech: If we change to make
p:empty the default, then the no context error is ok, but that
you'd have to name the steps and make an explicit pipe into the
option binding is the major argument against this change.
... David made a good point in saying that in the majority of XPath expressions don't use the context.
... I think that's sort of right.
Norm: In most cases where you
don't need the document, you can probably use the shortcut
... In cases where you can't use the shortcut syntax, the question is which is more common, expressions that do or don't need the context.
Vojtech: We could make it more explicit in the spec.
Mohamed: When we don't need any
context, we can use the shortcut syntax. When you need the
context, we can say that you need it for two different
... One is to evaluate variables and the other is to evaluate nodes from the document.
... What we can say is that the context of the shortcut syntax is allowed to reference variables but not the context.
Norm: In the shortcut syntax, you only get literal values, you don't get any variables at all.
Mohamed: I'm ok with the status
... I don't think making the proposed change is a good option.
Richard: Is there anywhere else where there is a port that doesn't get bound to the default readable port by defalt?
Norm: No, I don't think so.
Richard: So this would be an odd inconsistency: a place where the default for the binding is not the same as the default everywhere else.
Vojtech: What about parameter input ports?
Norm: Yeah, the binding rules for
parameter input ports are a little different.
... Anyone need further discussion to work out what they think the right thing to do is?
Norm: Is there anyone on the call that supports changing the status quo?
<scribe> ACTION: Norm to reply to the commenter on behalf of the working group. [recorded in http://www.w3.org/2008/12/11-xproc-minutes.html#action01]
Comments 015, 019
Vojtech: Does UUID generate one uuid, or one for each replacement?
Norm: It generates one and uses it everywhere.
Vojtech: Then the question is, should these be XPath extension functions or steps?
Norm: And you also asked if they should just return a c:result with the value.
Vojtech: Yes. I think it would be much more useful if it did, because you usually want to use it to construct a full URL.
Norm: Yes, perhaps that would have been better...
Mohamed: I made a proposal like this on 24 April.
Vojtech: The main problem I have with this is that it's sort of two string-replace steps, so it's innefficient.
Vojtech: It seems very strange.
Norm: Yes, it's strange. We probably ought to have done it the way you suggest. But is it worth going back to Last Call?
Paul: If it's a change we really want to make, I think we should see if we can do it without going back to Last Call.
Vojtech: You can simulate what I was proposing by using your own empty c:result as the input.
Norm: So, worst case, if we don't
change anything, we've got something that's a little odd but
not actively harmful.
... Let's sse if we can summarize where we are. We might like to change the way p:uuid, p:hash, and p:www-form-url-encode
... so that they simply return a c:result with the result, instead of behaving like string-replace. However, you can simulate
... that behavior yourself by using a c:result as the input. So there's no critical difference in functionality, it's mostly a question of aesthetics.
Norm: I propose that we leave the status quo, but try not to repeat this error in the future
First question, how does www-form-urldecode deal with parameter names that contain colons?
Vojtech: I don't think the spec
says anything about that.
... We can define a dynamic error.
Norm: Or we could translate the ":" into some other character like "_"
Vojtech: I'm reluctant to try to make some possibly complex rules for translations.
Norm: Anyone think it's a bad idea to make it a dynamic error?
No one says so.
Norm: We can say that for urldecode, if the resulting name is not a valid NCName, that's an error.
Everone seems happy with that.
Norm: Then what do we do for encoding, we could just use the localname.
Voytech: Then you may end up with duplicatews
Norm: Yep, that's true.
Vojtech: Sometimes you don't have a prefix at all, so you'd have to manufacture them.
Norm: Presumably that completely
defeats the purpose 99% of the time.
... Any other proposals besides just using the localname?
Vojtech: In most cases when you want to use form-urlencode, it's to create simple request strings. If you want ot encode parameters in a namesapce with prefixes, then you're doing something weird.
Norm: Right. You can't use these
convenience steps if you're operating outside their
... So, go with the localname?
... Any objections?
Vojtech: It says if any parameter name occurs more than once, the result will contain more than one c:param, but it doesn't say what order they occur in.
... Proposal: the document order of the c:params will correspond to the occurrence of parameters reading the input string from left to right.
Norm summarizes the issue
Norm: So what I'm hearing is, we expect p:http-request to follow redirections, handle cookies, etc., as described in the HTTP and related specs, but the behavior of p:document and friends is implementation defined with respect to this behavior.
Mohamed: We can follow XSLT and Schema that don't say anything about that.
Richard: Doesn't anyone follow redirections? It doesn't seem reasonable to not follow redirecgts.
Norm: Ok, maybe it's just cookies.
<scribe> ACTION: Norm to investigate what the features in question actually are. [recorded in http://www.w3.org/2008/12/11-xproc-minutes.html#action02]