IRC log of xproc on 2007-07-05

Timestamps are in UTC.

14:18:13 [RRSAgent]
RRSAgent has joined #xproc
14:18:13 [RRSAgent]
logging to
14:18:16 [Norm]
Meeting: XML Processing Model WG
14:18:16 [Norm]
Date: 5 July 2007
14:18:16 [Norm]
14:18:16 [Norm]
Meeting number: 74, T-minus 17 weeks
14:18:16 [Norm]
Chair: Norm
14:18:17 [Norm]
Scribe: Norm
14:18:19 [Norm]
ScribeNick: Norm
14:18:50 [Norm]
Regrets: Richard, Alessandro
14:27:19 [Norm]
ht, I think you have strong feelings about this issue:
14:27:31 [Norm]
Will you start some email discussion about that when you have a chance?
14:28:12 [Norm]
Alessandro feels strongly the other way, I think, so I'm not going to try to resolve it today
14:30:27 [Norm]
I wonder if source on p:equal should be primary
14:34:11 [ht]
14:34:24 [ht]
I recommend searching for 'parameter' in the current draft
14:34:38 [ht]
It turns up several references to parameters wrt compound steps, which I _think_ is a bug
14:36:23 [Norm]
Got it, fixed I think.
14:37:02 [ht]
OK, so before I start this thread, at the moment I don't see _any_ mention of pipeline parameters except in that Ed Note
14:37:20 [ht]
So as things stand, there is no way to get at them at all
14:37:39 [ht]
So I should cover that in my email, right?
14:40:11 [Norm]
I believe that if you specify <p:input port="p" kind="parameter"/> on your p:pipeline, you can get them explicitly
14:40:20 [Norm]
Though that's probably not clearly (enough) specified
14:41:11 [ht]
Where is it specified at all?
14:41:42 [Norm]
14:42:19 [Norm]
Yeah. Ok. s/clearly (enough)/at all/ :-)
14:42:39 [ht]
OK, I'll try to make a proposal
14:43:00 [Norm]
14:43:37 [Norm]
I think our recent decisions wrt defaulting stdin/stdout on the pipeline strengthen your position
14:48:37 [ht]
Perhaps -- I have to think through what's the right thing wrt just getting _explicit_ access first, I guess
14:48:52 [ruilopes]
ruilopes has joined #xproc
14:49:37 [Norm]
I hope that's nothing more than providing parameter inputs on the pipeline and referring to them
14:50:00 [Norm]
With a note that there's nothing wrong with having multiple parameter inputs that tool might let you bind to independently
14:50:30 [Norm]
$ xproc -params xslt -p x=y -p a=b -params query -p x=z -p a=c ...
14:50:56 [Norm]
...<p:input port="xslt" kind="parameter"/> <p:input port="query" kind="parameter"/> ...
14:51:09 [ht]
yeah, that seems about right
14:51:18 [ht]
and now I see what you meant above
14:51:31 [Norm]
Though the 99% case will be one parameter input that gets all the parameters
14:51:45 [Norm]
And (I would guess) one default, anonymous one if you don't specify a parameter input
14:51:54 [ht]
in the absence of any such, you get an un-named parameter input which only is accessible by default. . .
14:52:01 [Norm]
14:52:40 [Norm]
And any pipeline author that doesn't like that can wire it up themselves
14:56:29 [ht]
How? That is, what name gathers up the un-grouped arguments?
14:57:24 [Norm]
I'm inclined to leave it implementation defined, but to say that you can't have any anonymous ones if you have any named ones
14:57:54 [ht]
Not sure I'm happy with that
14:58:02 [ht]
This will have to wait until after the call now, sorry
14:58:11 [Norm]
No worries, I didn't expect to resolve it today
14:58:31 [MoZ]
Zakim, what is the code ?
14:58:31 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), MoZ
14:58:39 [Zakim]
XML_PMWG()11:00AM has now started
14:58:46 [Zakim]
14:59:23 [Zakim]
+ +95247aaaa
14:59:32 [Norm]
zakim, aaaa is MoZ
14:59:32 [Zakim]
+MoZ; got it
15:00:34 [Zakim]
15:00:40 [PGrosso]
PGrosso has joined #xproc
15:00:42 [ruilopes]
zakim, [ip is me
15:00:42 [Zakim]
+ruilopes; got it
15:01:09 [Zakim]
15:01:44 [ht]
zakim, please call ht-781
15:01:44 [Zakim]
ok, ht; the call is being made
15:01:46 [Zakim]
15:02:05 [Norm]
zakim, who's on the phone?
15:02:05 [Zakim]
On the phone I see MoZ, ruilopes, PGrosso, Ht, Norm
15:02:22 [Norm]
MSM, are you planning to join us?
15:02:23 [Zakim]
15:04:39 [Andrew]
Andrew has joined #xproc
15:05:38 [Zakim]
15:05:42 [Andrew]
zakim, ? is Andrew
15:05:42 [Zakim]
+Andrew; got it
15:05:44 [Norm]
Present: Norm, Mohamed, Rui, Paul, Henry, Murray, Andrew
15:05:51 [Norm]
Topic: Accept this agenda?
15:05:51 [Norm]
15:06:18 [Norm]
15:06:22 [Norm]
Topic: Accept minutes from the previous meeting?
15:06:22 [Norm]
15:06:29 [Norm]
15:06:34 [Norm]
Topic: Next meeting: telcon 12 July 2007
15:07:35 [Norm]
Richard's regrets continue; probably regrets from Mohamed, Henry until 16 August.
15:07:42 [Norm]
Topic: Review of 6 July 2007 Working Draft
15:07:42 [Norm]
15:09:17 [Norm]
Murray: On some fourth level headings, the formatting looks a bit odd.
15:09:59 [Norm]
ACTION: Norm to do something about the formatting of fourth level headings
15:10:28 [Norm]
Murray: In particular, since we have an element name in there, having it in u/c is a problem.
15:10:42 [Norm]
Mohamed: Some small editorial problems that I sent to Alex didn't get incorporated.
15:11:22 [Norm]
...and error codes are in an odd order.
15:11:28 [Norm]
ACTION: Norm to sort them
15:11:36 [Norm]
s/them/the error codes in the appendix/
15:13:17 [Norm]
Mohamed: What about p:map?
15:13:26 [Norm]
Norm: Yes, we still need to talk about that, but I don't think it'll get in this draft.
15:15:04 [Norm]
Mohamed: We have a schematron reference but no schematron step.
15:15:30 [Norm]
Norm: I thought we had agreed to have a schematron step.
15:15:39 [Norm]
Henry: Seems reasonable to me, along with XSLT2 and XSL Formatter.
15:15:58 [Norm]
Mohamed: We may also want to have an NVDL step.
15:16:00 [Norm]
Norm: Yes.
15:16:12 [Norm]
Norm: I'd like someone to propose how the NVDL step would work.
15:16:19 [Norm]
Murray: What about an appendix for the WG members.
15:16:21 [Norm]
Norm: Sure.
15:17:58 [Norm]
Proposal: We'll publish this as a public Working Draft tomorrow.
15:18:05 [Norm]
15:18:19 [Norm]
Topic: Step library issues
15:18:19 [Norm]
15:18:47 [Norm]
Norm: Let's struggle on in Alex's absence.
15:19:09 [Norm]
Norm: What about parsing HTML?
15:20:18 [Norm]
Henry: I seem to recall that if we said the content-type was text/html, then you get an implementation defined mapping from HTML to XHTML.
15:20:52 [Norm]
Norm: Should we do it that way?
15:21:12 [Norm]
Henry: There was an implicit reference to the HTTP request step that it by default produces escaped markup.
15:21:25 [Norm]
Norm: I hope that's wrong.
15:21:53 [Norm]
Henry: We have an unescape markup step because we know that Atom, RSS, NewsML, etc can encapsulate documents with escaped markup.
15:22:14 [Norm]
...So it seems that p:http-request and p:unescape-markup have this problem.
15:22:31 [Norm]
...but what do save/serialize have to do with this?
15:22:42 [Norm]
Henry: I'd like to split receiving and producing.
15:23:22 [Norm]
Henry: How about: it's implementation defined if any media types under than application/xml or application/foo+xml are allowed. Processors are not required to support any other media types. But if they do, then it's implementation defined what mechanism they use to get from the ones they support to XML.
15:23:30 [Norm]
Murray: Are we still talking about infosets?
15:23:37 [Norm]
Henry: Yes, that's why this problem arises
15:24:03 [Norm]
Murray: So it's implementation defined how you build an infoset from something that isn't XML.
15:24:36 [Norm]
Norm: I'm happy with Henry's proposal as a starting point.
15:25:11 [Norm]
Murray: I'm worried about how many different kinds of implementation-defined we're going to get.
15:25:59 [Norm]
Murray: In GRDDL, we have an issue called faithful infosets. This arises because in GRDDL, we're talking about XPath node trees and there are questions about validation and XInclude, etc.
15:26:11 [Norm]
...This seems to create another faithful infoset issue.
15:26:52 [MoZ]
q+ to ask Murray on the difference between XPath node trees and infosets
15:28:16 [Norm]
Scribe stepped away, a few minutes lost
15:28:30 [Norm]
Henry: The things you can depend on are the minimal common subset that more-or-less the infoset defines
15:28:44 [Norm]
...It's true that there's more in the XPath 2.0 datamodel, but you can't get at it from our language.
15:30:46 [Norm]
Norm: I'm sympathetic because of web services like Flickr that allow users to get comments
15:31:03 [Norm]
Murray: I think everything needs to be able to filter to XML or you need to have a specific component that's for loading non-XML things
15:31:17 [Norm]
Henry: I think Murray is right, but we're going to cheat just a little bit and say there are two.
15:31:37 [Norm]
...I'm happy that if you want to inject HTML into your pipeline and gaurantee that it's XML then you have to use http-request.
15:32:16 [MoZ]
15:33:42 [Norm]
Norm: We have load, basically only to support DTD validation
15:33:45 [Norm]
ack MoZ
15:33:45 [Zakim]
MoZ, you wanted to ask Murray on the difference between XPath node trees and infosets and to
15:34:04 [Norm]
Mohamed: I have a problem with components that translate from HTML to XML.
15:34:51 [Norm]
Norm: I want it to be implementation defined.
15:35:07 [Norm]
Mohamed: Norm, you said HTML to XHTML, but maybe we just meant HTML to XML.
15:35:14 [Norm]
Henry: Yes, I think that was my fault. All we need is XML.
15:37:53 [Norm]
Murray outlines a recent GRDDL use case about faithfulness of a representation
15:38:54 [Norm]
Murray: My initial thought was that there should be a "garbage-in" step that could reach out and bring anything in.
15:40:39 [Norm]
Norm: I think implementors will provide this if we don't
15:41:44 [Norm]
Henry: The way I read this, you can specify that you require an application/html+xml media type and that will cause the pipeline to fail if you don't get it.
15:41:57 [MoZ]
q+ to speaks about the difference between p:parameter namespace=""... and p:option without namespace@
15:42:31 [Norm]
Murray: I do an http-request and what I get back is an HTML document. I run some kind of process over that and I get some result. That result may be successful or not successfull.
15:42:41 [Norm]
...What comes out of http-request will be the result.
15:42:48 [MoZ]
15:42:53 [Norm]
...But presumably I as the author of the pipeline want to know a couple of things.
15:43:25 [Norm]
Norm: I think you can find all of those things by looking at the headers and body you get back.
15:43:54 [Norm]
Henry: If you're using tidy, I'll expect implementations to fail if tidy throws errors.
15:44:06 [Norm]
Norm: I agree.
15:44:18 [Norm]
Henry: If you're using tagsoup, then you know you'll always get an output.
15:45:49 [ht]
q+ to register a concern about the architecture of p:http-request
15:46:10 [Norm]
ack MoZ
15:46:10 [Zakim]
MoZ, you wanted to speaks about the difference between p:parameter namespace=""... and p:option without namespace@
15:46:34 [Norm]
Mohamed: Are we sure that the parameters of the header will be available to the next step?
15:47:05 [Norm]
...The http-request step will ask with some parameters, the result will be one of those.
15:47:42 [Norm]
Murray: So the http-request does a get and there are some headers.
15:48:07 [Norm]
Norm: You get those back in the headers.
15:48:26 [Norm]
ack ht
15:48:26 [Zakim]
ht, you wanted to register a concern about the architecture of p:http-request
15:48:57 [Norm]
Henry: If no one else is worrying about this, that's ok, because I'm only looking at this in detail now.
15:49:10 [Norm]
...Had we already discussed doing this using two output ports instead?
15:49:32 [Norm]
...I'd like to be able to write a take-my-chances pipeline where the primary output is a sequence of documents.
15:49:47 [Norm]
...And only if I care about the minutia do I look at the port.
15:50:47 [Norm]
Norm: I'm not sure how I'd handle multipart related.
15:50:54 [Norm]
s/I'd/that would/
15:51:09 [Norm]
Henry: An alternative would be to say that there is an option that says "take my chances"
15:51:27 [Norm]
Henry: I want a sequence of documents or fail, don't bother me with all this stuff.
15:52:06 [Norm]
Norm: That's not on the table now, but if you can fire off a quick message before you go on vacatoin, that would be good.
15:52:08 [MoZ]
q+ to ask the question why p:store/!result is not primary but not p:xslformatter/!result
15:52:27 [Norm]
ack MoZ
15:52:27 [Zakim]
MoZ, you wanted to ask the question why p:store/!result is not primary but not p:xslformatter/!result
15:53:11 [Norm]
Norm: Oversight, I agree.
15:53:41 [Norm]
Mohamed: What is the default for required on option?
15:53:48 [Norm]
Norm: "no"
15:53:58 [Norm]
Mohamed: It's written explicitly in some places.
15:54:41 [Norm]
Norm: Are we satisified that we've given editorial direction to Alex
15:55:54 [Zakim]
15:56:01 [Norm]
Norm attempts to describe the serialization problem that probably caused Alex to lump them together.
15:56:07 [Norm]
Topic: Any other business?
15:56:12 [Norm]
15:56:29 [Zakim]
15:56:30 [Zakim]
15:56:31 [Zakim]
15:56:33 [Zakim]
15:56:35 [Zakim]
15:56:36 [Zakim]
15:56:37 [Zakim]
XML_PMWG()11:00AM has ended
15:56:38 [Zakim]
Attendees were Norm, +95247aaaa, MoZ, [IPcaller], ruilopes, PGrosso, Ht, Murray_Maloney, Andrew
15:56:44 [PGrosso]
PGrosso has left #xproc
15:59:34 [Norm]
15:59:41 [Norm]
rrsagent, set logs world-visible
15:59:44 [Norm]
rrsagent, draft minutes
15:59:44 [RRSAgent]
I have made the request to generate Norm