XML Processing Model WG

11 Dec 2008


See also: IRC log


Norm, Paul, Mohamed, Vojtech, Andrew, Richard


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/12/11-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/11/20-minutes


Next meeting: telcon 18 Dec 2008?

No regrets given.

Meeting dates for the rest of December.

Skip 25 Dec and 1 Jan; next meeting 8 Jan.

Review of comments received so far on our CR

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/

024: Objection to XProc (p:with-option/p:with-param)

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C024

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 syntax.
... 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 reasons.
... 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 quo.
... 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?

None heard.

Norm: Is there anyone on the call that supports changing the status quo?

None heard.

<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.

<MoZ> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Apr/0065.html

<MoZ> http://www.w3.org/XML/XProc/2008/05/01-minutes

Vojtech: The main problem I have with this is that it's sort of two string-replace steps, so it's innefficient.

Norm: Yep.

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


016: How does www-form-urlencode/decode deal with parameters in a namespace?

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?

None heard.

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 range.
... So, go with the localname?
... Any objections?

None heard.


020: p:www-form-urldecode clarifications

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.

Norm: Right.
... Proposal: the document order of the c:params will correspond to the occurrence of parameters reading the input string from left to right.


027: http-request, redirection, and cookies

Norm summarizes the issue

Some discussion.

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]

Any other business?

None heard.


Summary of Action Items

[NEW] ACTION: Norm to investigate what the features in question actually are. [recorded in http://www.w3.org/2008/12/11-xproc-minutes.html#action02]
[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/12/11 17:12:45 $