15:54:49 <RRSAgent> RRSAgent has joined #xproc
15:54:49 <RRSAgent> logging to http://www.w3.org/2009/01/22-xproc-irc
15:54:52 <Norm> Zakim, this will be tag
15:54:52 <Zakim> I do not see a conference matching that name scheduled within the next hour, Norm
15:54:56 <Norm> Zakim, this will be xproc
15:54:56 <Zakim> ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 6 minutes
15:55:59 <Norm> Meeting: XML Processing Model WG
15:55:59 <Norm> Date: 22 Jan 2009
15:55:59 <Norm> Agenda: http://www.w3.org/XML/XProc/2009/01/22-agenda
15:55:59 <Norm> Meeting: 134
15:55:59 <Norm> Chair: Norm
15:56:00 <Norm> Scribe: Norm
15:56:03 <Norm> ScribeNick: Norm
15:57:29 <Norm> Considering which issues to discuss (apologies again for not providing more notice; I'll try to do better next week): 004 (again) 015, 022, 023, 035.
15:58:45 <PGrosso> PGrosso has joined #xproc
15:59:23 <Zakim> MoZ, you asked to be reminded at this time
16:00:16 <Norm> More possibilities: 017, 021, 025, 026, 027
16:00:29 <MoZ> Zakim, what is the code ?
16:00:29 <Zakim> the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MoZ
16:00:34 <Zakim> XML_PMWG()11:00AM has now started
16:00:43 <Zakim> +[ArborText]
16:01:35 <Zakim> +MoZ
16:01:37 <ht> ht has joined #xproc
16:03:44 <Zakim> +Norm
16:04:05 <Norm> Zakim, who's on the phone?
16:04:16 <Zakim> On the phone I see PGrosso, MoZ, Norm
16:04:21 <Zakim> +Vojtech
16:05:47 <ht> zakim, please call ht-781
16:05:48 <Zakim> ok, ht; the call is being made
16:05:49 <Zakim> +Ht
16:05:58 <Norm> Present: Norm, Paul, Mohamed, Henry, Vojtech
16:06:41 <Norm> Topic: Accept this agenda?
16:06:41 <Norm> -> http://www.w3.org/XML/XProc/2009/01/22-agenda
16:06:44 <Norm> Accepted.
16:06:51 <Norm> Topic: Accept minutes from the previous meeting?
16:06:51 <Norm> -> http://www.w3.org/XML/XProc/2009/01/08-minutes
16:06:55 <Norm> Accepted.
16:07:03 <Norm> Topic: Next meeting: telcon 29 Jan 2009?
16:07:27 <Norm> Paul gives regrets.
16:07:46 <Norm> Topic: CR comments
16:07:50 <Norm> -> Topic: Next meeting: telcon 29 Jan 2009?
16:08:01 <Norm> -> http://www.w3.org/XML/XProc/2008/11/cr-comments/
16:08:08 <Zakim> +Alex_Milowski
16:08:22 <Norm> Present: Norm, Paul, Mohamed, Henry, Vojtech, Alex
16:08:42 <Norm> Topic: 004: preserving base URI
16:10:06 <alexmilowski> alexmilowski has joined #xproc
16:10:09 <Norm> Henry: This whole thing is hugely complicated and it's not made at all easier by the fact that none of the relevant XML specs are really consistent with one another.
16:10:25 <Norm> ...It's not the case that it's easy for us to say that we should do it like everyone else, because they all do it differently.
16:10:52 <Norm> ...The Infoset says that if you assemble a document out of multiple general entities, the base URI changes accordingly.
16:11:01 <Norm> ...But it doesn't have a serialization or any sort of base URI fixup.
16:11:25 <Norm> ...On the other end of the spectrum, XInclude (V1) said that you had to insert xml:base attributes and change the infoset.
16:11:55 <Norm> ...In the middle, we have XSLT which will change the base URI if you add xml:base attributes, but can't preserve them when copying.
16:12:58 <Norm> ...So the one observation that Richard made that I point to in this email:
16:13:11 <Norm> -> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html
16:13:41 <Norm> ...is that XML Base is a bit like character entities or namespace declarations. They're there in order to effect the infoset, but they're not part of the document. They're metadata.
16:14:01 <Norm> ...And therefore, there's no guarantee that they're going to be there when you serialize.
16:14:21 <Norm> ...So it's not completely outrageous to think that you might loose base URI information when you serialize.
16:14:49 <Norm> Alex: It seems that if you delete the xml:base attribute, then you get what you deserve if you really wanted to preserve the base URI.
16:15:34 <Norm> Henry: At the moment, I'm inclined towards the position that we should sort of follow XSLT: if you delete an xml:base attribute, it does not change the base URI attribute of the element.
16:15:41 <Norm> Alex: But you lose it if you serialize.
16:16:17 <Norm> Henry: Yes. In the same way that a parser takes account of general entity structure and the base URIs, but they won't be preserved when yous serialize.
16:16:51 <Norm> Henry: What Richard eventually conceded, is that if we leave the spec the way it is, he can still serialize between steps and carry the base URI out-of-band.
16:18:45 <Norm> Straw poll: Removing the xml:base attribute (a) removes the base URI property from the infoset or (b) does not change it. 
16:19:13 <Norm> Zakim, who's on the phone?
16:19:13 <Zakim> On the phone I see PGrosso, MoZ, Norm, Vojtech, Ht, Alex_Milowski
16:20:14 <Norm> Results: Five for (b) no change, 1 abstention.
16:20:47 <Norm> Vojtech: If I really want to remove the base URI information, then I should ... add an xml:base attribute with the value from the parent.
16:22:27 <Norm> Some discussion of serialization.
16:23:19 <Norm> Henry: Are we also in agreement that we do have to update the spec everywhere you can do something that can add or change the value of an attribute to say that if the attribute is added/changed is the xml:base attribute, this causes a change to the XML base property.
16:23:43 <Norm> Norm: Anyone who disagrees?
16:23:47 <Norm> None heard.
16:24:33 <Norm> ACTION: Norm to edit the spec so that we say that any change to xml:base or adding an xml:base does change the underlying infoset property.
16:25:26 <Norm> Topic: 015 p:uuid question
16:26:52 <Norm> Vojtech: The question of whether it generates one UUID or many has been answered: it generates one UUID.
16:27:02 <Norm> ...The remaining question is whether this step needs additional options or parameters.
16:28:19 <Norm> Norm: Do we know what the parameters/options are?
16:29:22 <Norm> Some discussion of the various types of UUID.
16:31:07 <Norm> Norm: I think the question is, do we leave other versions implementation-defined, or do we try to add parameters/options to make it interoperable.
16:31:37 <Norm> Alex: I think we should provide the options.
16:31:44 <Norm> Vojtech: In Java you can generate type 3.
16:32:07 <Norm> Vojtech: I was thinking maybe it was sufficient to do for p:uuid what we do for p:hash
16:34:29 <Norm> Norm: To be honest, I think for V1 we should just make the parameters that are needed for other UUID formats implementation defined.
16:34:38 <Norm> More discussion about the virtues of parameters instead of extension attributes.
16:34:50 <Norm> Vojtech: Why don't we just say that the only supported version is version 4.
16:35:52 <Norm> Alex: I guess I could live with implementation defined.
16:36:30 <Norm> Proposal: Implementations must support version=4, support for other versions (and how options/parameters are provided for those versions) is implementation-defined.
16:36:46 <Norm> Accepted.
16:37:13 <Norm> Topic: 022 p:http-request default method
16:37:54 <Norm> Norm: If you don't specify a method on p:http-request, do we work it out dynamically or do we make method required?
16:38:09 <Norm> Alex: I think we should make it a required attribute.
16:38:25 <Norm> Norm: That's what I thought too, in email following up.
16:38:43 <Norm> Proposal: The method is required, it is an error to attempt to use p:http-request without a specified method.
16:38:54 <Norm> Accepted.
16:39:19 <Norm> Topic: 023 p:http-request - POST with no c:body
16:39:29 <Norm> Vojtech: I think that's clear now, you can do a post withotu a body.
16:39:35 <Norm> s/withotu/
16:40:17 <Norm> Norm: Is there any distinction between no c:body and an empty c:body?
16:40:48 <Norm> Alex: I think if you specify an empty body, you get a content-length: 0, and if you don't specify a body, you don't get any entity body.
16:40:56 <Norm> Proposal: Yes, you can have a POST with no c:body element.
16:41:08 <Norm> Accepted.
16:41:37 <Norm> Topic: 035 instance name visible to custom step
16:42:47 <Norm> Norm: I think James is asking for the ability to get the step name without passing it as a separate option. Looks like creeping featurism to me: not in V1?
16:43:01 <Norm> Proposal: Not in V1.
16:43:05 <Norm> Accepted.
16:43:40 <Norm> Topic: 017 p:xquery and XQueries that cannot be evaluated.
16:43:54 <Norm> Vojtech: I thought that in the XQuery step we should have an error for reporting bad XQuery.
16:44:12 <Norm> Norm: A particular error code for "couldn't understand the query"?
16:44:28 <Norm> Vojtech: Yes, I think we could put all the possible errors in one error code.
16:45:42 <Norm> Alex: Could we add an error for "unable to process input", we could use it for XSLT, XQuery, XML Formatter. I could use it for a SPARQL step if I had one, etc.
16:47:15 <Norm> Alex: These could apply to the validator steps as well.
16:47:37 <Norm> Proposal: A generic error for "unable to process input/input format wrong/etc." that all steps (including custom steps) can throw when appropriate.
16:47:52 <Norm> Accepted.
16:48:08 <Norm> Topic: 021 Replacing the document node in p:string-replace
16:48:25 <Norm> Vojtech: I was wondering what happens if you replace the document element with an empty string in p:string-replace. 
16:48:29 <Norm> ...Does this call XD0001?
16:48:34 <Norm> ...One of the answers was 'yes'.
16:48:48 <Norm> Norm: Yep, that works for me.
16:50:14 <Norm> Vojtech: I was trying to write a test for this.
16:50:33 <Norm> Norm: We don't require processors to produce exactly the right errors, but it's still good to be clear.
16:50:38 <Norm> Proposal: Close without action.
16:50:49 <Norm> Accepted.
16:51:13 <Norm> Topic: 025 p:unescape-markup "namesapce"
16:51:18 <Norm> s/namesapce/namespace/
16:51:49 <Norm> Vojtech: You can have a wrapper element which if you unesacpe the content then you get five elements inside. The text about unescape-markup talks about a single document element.
16:52:05 <Norm> ...I think that phrasing should be changed so that it covers the case where unescaping gives five elements (or no elements) in the wrapper.
16:52:42 <Norm> ...I think it should be applied to each of the elements in the wrapper.
16:53:00 <Norm> Alex: The way I look at this is, when you provide the default namespace, it's like you're wrapping the whole thing in a pseudo-element that you can throw away.
16:53:12 <Norm> ...that's effectively the behavior.
16:53:51 <Norm> Norm: It sounds like this is mostly editorial, handling the case where there are multiple or no elements.
16:54:28 <Norm> Vojtech: Issue 080 is related: if you specify a namespace but the unescaped content already has a default namespace.
16:54:45 <Norm> ...Or if the element declares other namespaces. Are they effected?
16:55:26 <Norm> Alex: If you take the escaped content, treat it as if it was wrapped in an element with a default namespace declaration, and then take it's children. That's what should happen.
16:56:55 <Norm> Norm: I think the practical upshot is that the answer is that if there are default namespace bindings in the content, those bindings "win" and it has no effect on any other namespace declarations.
16:57:07 <Norm> Vojtech: The spec currently gives the impression that it overrides the defalut.
16:57:21 <Norm> Norm: I agree, the spec is confusing.
16:58:19 <Norm> Proposal: Close 025 with no action, close 080 with an action to the editor to clarify the spec so that any specified namespace clearly does not override any explicit declarations in the escaped content.
16:59:20 <Norm> Vojtech: Part of my question in 025 was about the case where you have no root elements or more than one.
16:59:22 <Norm> Norm: Right.
16:59:46 <Norm> Proposal: Close 025 with an action to the editor to clarify the case where unescaping produces no elements or more than one element, close 080 with an action to the editor to clarify the spec so that any specified namespace clearly does not override any explicit declarations in the escaped content.
17:00:09 <Norm> Accepted.
17:00:16 <Norm> ACTION: Norm to edit the spec to fix 025 and 080.
17:00:22 <Norm> Topic: Any other business?
17:00:24 <Norm> None heard.
17:00:26 <Norm> Adjourned.
17:00:30 <Zakim> -PGrosso
17:00:31 <Zakim> -Norm
17:00:33 <Zakim> -MoZ
17:00:35 <Zakim> -Vojtech
17:00:38 <Zakim> -Alex_Milowski
17:01:03 <PGrosso> PGrosso has left #xproc
17:02:31 <Norm> RRSAgent, make logs world-visible
17:02:35 <Norm> RRSAgent, draft minutes
17:02:35 <RRSAgent> I have made the request to generate http://www.w3.org/2009/01/22-xproc-minutes.html Norm
17:02:42 <Norm> Zakim, bye
17:02:42 <Zakim> leaving.  As of this point the attendees were PGrosso, MoZ, Norm, Vojtech, Ht, Alex_Milowski
17:02:42 <Zakim> Zakim has left #xproc
17:02:57 <Norm> RRSAgent, bye
17:02:57 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2009/01/22-xproc-actions.rdf :
17:02:57 <RRSAgent> ACTION: Norm to edit the spec so that we say that any change to xml:base or adding an xml:base does change the underlying infoset property. [1]
17:02:57 <RRSAgent>   recorded in http://www.w3.org/2009/01/22-xproc-irc#T16-24-33
17:02:57 <RRSAgent> ACTION: Norm to edit the spec to fix 025 and 080. [2]
17:02:57 <RRSAgent>   recorded in http://www.w3.org/2009/01/22-xproc-irc#T17-00-16