IRC log of xproc on 2008-10-23

Timestamps are in UTC.

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