06:58:32 RRSAgent has joined #xproc 06:58:32 logging to http://www.w3.org/2008/10/23-xproc-irc 06:58:39 Zakim, this is xproc 06:58:39 sorry, Norm, I do not see a conference named 'xproc' in progress or scheduled at this time 07:03:26 Zakim, call xproc 07:03:26 sorry, Norm, I don't know what conference this is 07:06:44 Meeting: XML Processing Model WG 07:06:44 Date: 23 Oct 2008 07:06:44 Agenda: http://www.w3.org/XML/XProc/2008/10/tpac-agenda 07:06:44 Meeting: 128 07:06:44 Chair: Norm 07:06:46 Scribe: Norm 07:06:48 ScribeNick: Norm 07:07:20 Present: Zarella (PTC), Mohamed, Vojtech, Norm, Alex 07:08:15 MoZ has joined #xproc 07:08:51 Zakim, what is the code ? 07:08:51 sorry, MoZ, I don't know what conference this is 07:08:58 Zakim, list 07:08:58 I see IA_XHTML2()3:00AM, SW_OWL(F2F)2:30AM, SEC_WSCWG()3:00AM active 07:08:59 also scheduled at this time are WAI_EOWG()1:00AM, GA_SVGWG()2:30AM, AB_(TPAC)2:30AM, WAI_AUWG()2:00AM, T&S_EGOV()3:00AM, IA_MAWG()3:00AM 07:09:15 Vojtech has joined #xproc 07:09:16 alexmilowski has joined #xproc 07:09:23 Topic: Accept this agenda? 07:09:23 -> http://www.w3.org/XML/XProc/2008/10/tpac-agenda 07:10:45 Mohamed: Is everyone going to be here this afternoon? 07:11:00 Norm: The AC meeting is this afternoon, we'll see what happens. 07:11:11 Norm: We can rearrange the agenda if necessary. 07:11:34 Agenda accepted, for the time being. 07:12:29 Vojtech: What is the default XML processing model? 07:12:51 Norm: It's the other work item on our charter; in the absence of any explicit instructions, what processing should an XML processor perform. 07:12:58 Norm: We need to start thinking about that itme. 07:13:00 s/itme/item/ 07:13:07 Topic: Accept minutes from the previous meeting? 07:13:07 -> http://www.w3.org/XML/XProc/2008/10/02-minutes 07:13:53 Accepted. 07:14:25 Topic: Remaining open last call issues 07:14:46 Topic: 015: Add p:encrypt/p:decrypt steps 07:15:27 Norm: Following discussions with the XML Security WG, we're not likely to have any definitions in time for V1. 07:15:34 Mohamed: What about having simple steps with parameters? 07:16:09 Norm: I don't see how that provides any more interoperability than just letting implementors do it in their own namespace. 07:16:17 Proposal: close with no action. 07:16:23 Accepted. 07:16:53 Topic: 030: LCWD comments from the XQuery WG 07:17:02 Norm: I think these are all ok, but I haven't implemented them yet. 07:18:30 Alex: Where did we leave off? 07:18:59 Norm: We just need to be careful that introducing "implementation defined namespaces" doesn't leak outside the XQuery step. But I don't think that's going to be a problem because we have an XML syntax. 07:23:51 Alex: Do we need to say something about who wins when they come from both places? 07:24:29 Norm: So if my p:xquery call has a foo: namespace declaration and my XQuery implementation predefines the foo: namespace (differently), who wins? 07:26:17 Alex: It seems like the right answer would be, we stuff our things into the static context and that overrides what was in the by default. 07:27:39 Norm: My guess is that the query processor starts and will overwrite anything that we put in the static context. 07:28:14 ACTION: Alex/Norm to investigate how this actually works. 07:29:24 Mohamed: My thought was about all the validation steps. Is there a static context for them too? 07:29:47 Alex: For schema there isn't. 07:30:43 Mohamed: All the steps make it clear what is declared in XProc but XQuery is starting to make us think differently about it. 07:32:17 Norm: I don't think any of the other steps have this sort of defaulted namespace behavior. 07:33:18 Topic: 035: Another look at validate-with-xml-schema 07:33:52 Norm: I'm perfectly happy with Henry's proposal for lax/strict. 07:35:00 Norm: Then Henry goes on to propose some new options: use-schema-location and try-namespace. 07:35:27 Alex: I think use-schema-location is a really good idea. 07:38:13 Some discussion of whether or not parameters should be passed to the schema-validate step. 07:40:34 Norm: Let's set this one aside until Henry gets here. 07:41:37 Norm: The only thing you can't do with extension attributes is compute their values dynamically. I don't know how serious that is. 07:42:04 Topic: 036: Make 5.7.2 consistent wrt context node 07:43:13 http://www.w3.org/XML/XProc/docs/diff.html#p.option 07:43:19 s/http/-> http/ 07:45:54 Vojtech: Sometimes it's difficult to detect exactly why an XPath expression failed. 07:46:43 Proposal: Accept the changes. 07:47:31 Accepted. 07:49:43 Vojtech: If you define a default binding for p:input and you then refer to a variable not-in-scope, what happens? 07:49:51 Norm: The expression fails. 07:52:53 Norm: I think the upshot is that we need to say somewhere general that it's an error to refer to varible bindings that are not in scope. 07:53:48 ACTION: Norm to add a general statement about out-of-scope variables. 07:55:18 Mohamed: With respect to the binding of p:option, we should say that it's as if the binding was to p:empty then in 5.15 we should say what that means (empty in 1.0 and undefined in 2.0) 07:55:32 Norm: Makes sense to me. 07:55:50 Mohamed: Then maybe we wouldn't have to cut-and-paste that prose everywhere 07:55:55 Norm: Anyone disagree? 07:55:58 Accepted. 07:56:08 ACTION: Norm to fix p:empty and p:option as Mohamed suggests. 07:56:24 Topic: 035: Another look at validate-with-xml-schema 07:58:05 Henry: I chose these two options explicitly because these are the ones that you need to get Saxon to do the right thing. The default behavior changed between 8.0 and 9.0. 07:58:21 Henry: What exactly it means to "try namespaces" is implmeentation defined (RDDL, GRDDL, etc.) 07:58:50 Alex: For Xerces, if you turn off the use-schema-location hints and add a catalog, that'll just work. 07:59:09 Henry: Catalogs should be transparent. They enter the game at the time you have a URI that you're trying to dereference. 08:03:41 Alex: We need to be very clear about what try-namespaces it means. 08:04:09 Henry: We can point directly into the schema spec for the right paragraph and clause. 08:07:19 Alex: I have a catalog for my schema processor and I need to tell it where the catalog is. 08:07:31 ...I could do it externally, but that would be global in some way. 08:08:02 Henry: We haven't decided if parameters are a mechanism which people can use to extend the option set in implementation specific ways. 08:08:07 ...I don't think that's what they were intended for. 08:08:35 ...They were intended to operate in the case where it is in the nature of a particular step that it has an open-ended set of options. 08:09:42 Alex: We have steps that violate that: p:hash and p:validate-with-xml-schema 08:09:49 s/validate-with-xml-schema/xsl-formatter/ 08:10:21 Henry: Are we sure we're capable of predicting in advance which steps are likely to want parameters? Shouldn't every step have a parameter port? 08:10:42 Alex: Going back through last call? 08:11:09 Henry: Right, I've said it, but I agree we don't want to go through last call for it. 08:12:18 Vojtech: We have an explicit error for p:hash 08:12:31 Alex: Maybe we should make that a general "I didn't like your parameter" error. 08:13:21 ...The only thing I can see parameters for are weird implementation features. 08:13:44 Henry: Don't we really need a way to allow implementations to extend the list of options available on the step? 08:13:50 Alex: Can we do this in V.next 08:14:49 Henry: Yes, but it will be very disruptive. The p:hash and p:xsl-formatter steps will have these parameters when they don't need them anymore. 08:16:26 Henry: This would actually have the benefit of packaging things a little better. 08:19:18 Inspection of 3.8 08:19:50 Henry: It seems to me that extension attributes can be used to pass implementation-specific strings, but they are static. 08:21:46 Vojtech: Why don't we have a way to compute extension attribute values? 08:22:02 Norm: We decided not to do attribute value templates, and we don't have an element syntax for them. 08:23:02 Does anyone want to add a parameter input port to p:validate-with-schema? 08:23:11 No. 08:23:35 Do we want to add the use-location-hints and try-namespaces options ? 08:23:44 Yes. 08:23:48 Anyone object? 08:23:59 Accepted. 08:24:24 Are we happy with the proposed error? 08:24:24 yes. 08:25:46 Alex: Should we have the general error about bad parameters or bad parameter values? 08:25:50 Yes. 08:28:30 Break 09:11:26 Norm has joined #xproc 09:11:51 Norm has changed the topic to: XProc WG http://www.w3.org/XML/XProc/2008/10/tpac-agenda 09:12:03 Reconvene at 14:00 09:12:41 Zakim has left #xproc 09:13:48 ht has joined #xproc 12:08:49 RRSAgent has joined #xproc 12:08:49 logging to http://www.w3.org/2008/10/23-xproc-irc 12:08:50 Zakim has joined #xproc 12:10:15 MoZ has joined #xproc 12:11:36 Vojtech has joined #xproc 12:11:45 Topic: 037: Self-importing 12:13:44 Norm: I think we should allow it, but may require adding some prose about the base URI of the pipeline or library document. 12:15:44 Accepted. 12:16:13 Topic: 041: Steps with no inputs/outputs 12:16:14 ht has joined #xproc 12:17:11 Vojtech: We can import pipelines, not just libraries, but the prose talks about libraries. 12:17:24 Norm: Yes, that's probably just sloppy wording. I'll fix it. 12:17:44 ACTION: Norm to fix the wording about imports so that it applies equally to p:pipelines and p:libraries 12:19:23 Topic: 037: Self-importing 12:19:37 Vojtech: Does this include little self-contained compound steps? 12:19:39 Henry: Yes, this is fine. 12:21:24 Norm: There's no issue, we can just close this without action. 12:21:25 Accepted. 12:21:47 Topic: 042: Detecting errors 12:22:11 Norm: I asked if unknown steps were an error, and the consensus was that they are not. 12:22:51 Norm: I'm satisfied. 12:22:59 Norm: I propose we close this with no action. 12:23:47 ACTION: Norm to change 6.1 so that it's not a static error. 12:24:03 well 12:24:14 Norm, what does it means for the implementation ? 12:24:26 It means that it's a dynamic error if you attempt to evaluate it. 12:24:28 Which we already say 12:24:44 Does that make sense, MoZ ? 12:24:44 okidok 12:25:30 Topic: 044: Source on p:error 12:25:44 Norm: I think it should not be primary; Henry agreed. Any objections? 12:26:34 Vojtech: As long as you can bind something, I'm fine. 12:26:37 Accepted 12:26:53 Topic: 045: split-sequence and position() and last() 12:28:12 Norm: I was confused because of our changes to tracking position and length in for-each and viewport. 12:28:19 ...I think Mohamed is right and there's no problem. 12:28:28 Norm: Proposal: close without action. 12:28:30 Accepted. 12:28:45 Topic: 046: href on p:store 12:29:50 Norm attempts to explain the situation. 12:31:51 Norm: I think p:store w/o an href should write the document to the location of the base URI of the document being stored. 12:31:58 ...Though we appear not to actually say that yet. 12:32:19 Henry: If base URIs are propagated, doesn't that run the risk of blowing away the pipeline document. 12:32:46 Norm: If I have an XSLT step that produces a result document, and I p:store that result document, I want it to be written to the right URI. 12:35:40 Henry: See what we say at the top of section 7. If I feed file://important/document into a complex pipeline that has a p:store somewhere and I've forgotten to put href on it, we'll overwrite the document. 12:35:45 ...Is that really what we want? 12:36:16 Norm: We have our own base URI function (because XPath 1.0 didn't) 12:36:20 ...So you could say: 12:36:21 12:36:48 12:37:01 12:38:34 Henry: There are three options: (1) make it required, (2) give the empty string special status, perhaps an error, or (3) give it a default that we think does something useful, like /dev/null 12:40:05 Norm: If I have a p:xslt step that produces a bunch of secondary result documents and I want to write them to disk, I'll have to write the complex form of p:store in order to save the documents. 12:41:55 Henry: We could specify that the base URI for absolutization in p:store is the base URI of the primary input. 12:44:53 Alex/Norm: We could add a separate option for store to base-URI? 12:52:00 MoZ has joined #xproc 12:52:50 alexmilowski has joined #xproc 13:00:54 Henry: On balance, I think the facts are that you can get what you want and anything else puts carelessness at high risk. 13:01:19 Henry: But do we call the empty string an error? 13:02:26 Norm: No, becaues #foo would do the same thing. 13:02:34 Henry: So I think the consensus is that the href attribute is required. 13:06:07 Proposal: Make the href attribute required. 13:06:37 Accepted. 13:07:54 Topic: 047: p:wrap-sequence and position()/last() 13:08:23 Norm: I think Mohamed is right. 13:09:48 Norm: Proposal: Make it explicit that position() and last() are available in wrap sequence. 13:09:50 Accepted. 13:10:00 Topic: 048: p:log on atomic steps 13:12:12 Norm: This is a spec exposition bug. We just need to say somewhere that p:log can be used on all the atomic steps. 13:14:26 ACTION: Norm to change 3.3 so that it refers to with-option, variable, etc. 13:17:16 Accepted. 13:17:44 Topic: 049: Standard C14N method 13:21:52 Mohamed: I made a proposal and we talked about it and decided not to do it. 13:22:05 Alex: It should be put in the serialization spec, we shouldn't have to do it. It's something everyone wants. 13:22:21 Proposed: Close with no action. 13:24:52 Mohamed: I did make a request for an example. 13:24:54 Norm: I'm fine with that. 13:25:02 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Jun/0035.html 13:25:12 ACTION: Norm to add an example of C14N 13:25:58 Topic: Test suite 13:36:01 alexmilowski has joined #xproc 13:39:20 Review of use cases and requirements 13:47:51 ht has joined #xproc 13:49:28 ACTION: Norm to add our use cases and requirements document to the References 13:56:22 Use case 5.10 requires dsig, so we can't do that one. 14:00:07 Use case 5.11 requires a validator that preserves base URI properties. 14:04:17 Use case 5.14 requires tagsoup or tidy, so we can't do that one. 14:06:19 alexmilowski has joined #xproc 14:07:21 What's up with the git down? 14:11:23 Discussion of content-type on p:load and p:document to satisfiy 5.14 14:18:19 Mohamed observes that p:data can load non-XML resource, but we have no facility for doing that with a computed URI. 14:19:33 Mohamed: So we need to create another step or somehow extend p:load 14:20:17 Zakim has left #xproc 14:22:24 well... yes 14:23:01 Vojtech: You can't use text/plain on p:load because it doesn't provide a wrapper. 14:23:04 not even with with-option ? 14:24:49 Norm: Maybe this is how we decided to use p:http-request for this case... 14:24:55 yeah... 14:25:07 Mohamed: I want to fetch an xhtml document which is distributed as text/html so that I is able to work with it. 14:25:17 you can pass a computed URI with a 'file' scheme 14:25:19 (or whatever) 14:25:50 unescape-markup ... 14:26:14 HTML5 with need a "special" parser for sure... 14:26:47 "All strings are valid HTML5" ... 14:26:52 guess who said that... 14:27:00 :) 14:27:32 Besides... ISO-8859-1 is really Windows-1252 according to HTML5 ... 14:27:42 ...so, you really want p:data ... 14:27:50 (seriously... you really do...) 14:28:19 In fact... you want a byte sequence base64 encoding so you can run their crazy redefinition of character encodings 14:28:22 You want p:data, but you can't use p:data if you need to construct the URI 14:28:38 ACTION: Norm to fix the note in http-request that says unescape-markup will undo base64 encoding 14:28:40 If you get a text/html media type... 14:28:59 ...and it has a non-unicode encoding... 14:28:59 If you get back base64 encoded text, you're screwed. 14:29:03 do you get base64 ? 14:29:16 Note 14:29:16 Given the above description, any content identified as text/html will be base64-encoded in the c:body element, as HTML isn't always well-formed XML. A user can attempt to convert such content into XML using the p:unescape-markup step. 14:29:21 (checking spec) 14:31:07 Here's our note: 14:31:09 "Given the above description, any content identified as text/html will be base64-encoded in the c:body element, as HTML isn't always well-formed XML. A user can attempt to convert such content into XML using the p:unescape-markup step." 14:31:24 But: 14:31:26 "is recognized as a non-XML media type whose contents are encoded as a sequence of Unicode characters (e.g. it has a character parameter or the definition of the media type is such that it requires Unicode)," 14:31:48 That says that text/html; charset=UTF-8 should end up as characters and not base64 14:32:11 But text/html; charset=ISO-8859-1 should be base64 14:33:08 Thus... you might have to look at the 'encoding' attribute of 'c:body' to understand whether you have characters or not. 14:33:12 Ugly... 14:33:38 What we need is a media type parameter of 'version' 14:33:47 This is all very unsatisfying 14:33:48 so p:unescape-markup can use 14:34:10 text/html; charset=ISO-8859-1; version=5.0 14:34:13 Yes 14:34:19 What are the problems? 14:34:26 text/html isn't what you expect anymore... 14:34:37 1. p:data can load a non-XML resource, but can't do so with a computed URI 14:34:41 especially if they are going to codify the sins of the past... 14:34:59 that ISO-8859-1 will be treated as Windows-1252 (along with others) 14:35:03 alexmilowski, keep the html5 chatter in /me 's or something ok? 14:35:24 2. p:load takes a computed URI, but can't load non-XML data 14:35:43 I was talking about mohamed's want to use this for html 14:35:52 ..which led us to p:http-request... 14:35:59 so I thought we were talking about the same thing. 14:36:01 3. p:http-request can take a dynamic URI and can load non-XML data, but it's likely to base64 encode the result 14:36:17 4. And we don't have a way to unescape base64 encoded text 14:36:30 In (3) you get two different outputs for text/html 14:36:57 I think our note is wrong... am I correct or wrong? 14:37:08 ISO-8859-1 is not a unicode encoding... 14:37:14 so you get base64 for that... 14:37:28 UTF-8 is... so text/html; charset=UTF-8 gives you escaped html 14:37:42 Rather unfortunate 14:37:51 The note is wrong. 14:38:07 What we need is the "HTML munge" step... 14:38:09 But you're right about ISO-8859-1 text, which is still pretty common. 14:38:27 Or... we could have a "treat as text" option... 14:38:47 e.g. if you get text/* media type and, in theory, can map to unicode via the encoding... 14:38:53 then treat as text... 14:39:22 I hate to say this sounds like an issue we might want to take up while we are all here. 14:39:49 I'll come back... They aren't covering what I was interested in... 14:40:00 I'll be there soon as I can walk there... 14:47:08 Alex: We separated out the encoding on the result from http-request, but we don't seem to be doing this here. 14:47:17 ...c:data and c:body are slightly out of step in this regard. 14:53:34 Alex: You might want to choose what to do with data based on its encoding: even if it's a mappable encoding, you might want to treat it as data. 14:59:36 We need to clarify how/what encoding means on c:body when it appears in a response. 15:00:08 ACTION: Norm to clarify encoding on c:body in a response--probably by saying that it isn't used 15:07:45 Norm: I think there's consensus that we could make forward progress by saying that implementations SHOULD attempt to convert the content of any text/* media type into Unicode characters. Implementations MUST present text/* media types that use a Unicode encoding into characters. 15:23:57 Light breaks over Marblehead...the p:unescape-markup step *can* decode base64 encoded text. 15:27:01 Mohamed: We need encoding on c:data 15:27:29 Alex: That's right because it might or might not be base64 encoded. 15:28:36 Alex: In unescape-markup we need to say that there can be an charset parameter on the content-type. 15:33:20 Vojtech: We should remove the charset parameter's default value and say that it's only used if it's specified and it overrides the charset on the content-type. 15:36:59 alexmilowski has joined #xproc 15:39:38 Norm: What have we decided? 15:40:12 1. Remove the default value from the charset parameter on p:unescape-markup 15:42:13 2. Steps that take a content-type should respect the charset parameter 15:42:24 3. If you specify a charset on unescape-markup, it overrides the charset parameter on the content-encoding 15:45:55 4. If you don't specify the charset in either place, and the encoding is base64, that's a dynamic error 15:50:17 5. Change p:unescape-markup so that it ignores the charset if the encoding isn't specified. 15:51:38 6. If you want to load a non-XML resource, you're stuck with p:http-request 15:54:56 7. Specifically, it's not a dyanmic error if encoding isn't specified and the charset is 15:55:31 8. Add encoding attribute to c:data 15:56:56 9. Document that http-request can be used to load non-XML resources 15:58:42 Add an example that shows that there are a bunch of optoins that don't make sense 15:58:56 ACTION: Alex to go through the spec again and look at the encoding/charset things 16:08:58 RRSAgent, make logs world-visible 16:09:02 RRSAgent, draft minutes 16:09:02 I have made the request to generate http://www.w3.org/2008/10/23-xproc-minutes.html Norm 17:04:23 alexmilowski has joined #xproc