15:29:01 RRSAgent has joined #xproc 15:29:01 logging to http://www.w3.org/2006/01/12-xproc-irc 15:29:08 zakim, this will be xproc 15:29:08 ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 31 minutes 15:29:23 Meeting: XML Processing Model WG 15:29:23 Scribe: Norman Walsh 15:29:23 ScribeNick: Norm 15:29:23 Date: 12 Jan 2005 15:29:23 Chair: Norm 15:29:28 Agenda: http://www.w3.org/XML/XProc/2006/01/12-agenda.html 15:29:35 s/12 Jan 2005/12 Jan 2006/ 15:30:57 Norm has changed the topic to: XProc: http://www.w3.org/XML/XProc/2006/01/12-agenda.html 15:31:12 zakim, agenda+ Administrivia 15:31:13 agendum 1 added 15:31:41 zakim, agenda+ Technical: email followup 15:31:42 agendum 2 added 15:31:49 zakim, agend+ Requirements 15:31:49 I don't understand 'agend+ Requirements', Norm 15:31:52 zakim, agenda+ Requirements 15:31:52 agendum 3 added 15:55:00 Alessandro has joined #xproc 15:57:35 rlopes has joined #xproc 15:58:05 zakim, please call ht-781 15:58:23 ok, ht; the call is being made 15:58:27 XML_PMWG()11:00AM has now started 15:58:29 +Ht 15:59:16 Jeni has joined #xproc 15:59:30 +Jeni 15:59:49 +??P10 16:00:53 richard has joined #xproc 16:01:00 http://www.w3.org/XML/XProc/2006/01/12-agenda.html 16:01:03 ebruchez has joined #xproc 16:01:09 +[IPcaller] 16:01:16 +Norm 16:01:21 zakim, who's on the phone? 16:01:21 On the phone I see Ht, Jeni (muted), ??P10, [IPcaller], Norm 16:01:34 +??P30 16:01:36 zakim, ?p10 is richard 16:01:36 sorry, Norm, I do not recognize a party named '?p10' 16:01:38 PGrosso has joined #xproc 16:01:46 zakim, ?P30 is richard 16:01:46 sorry, Norm, I do not recognize a party named '?P30' 16:01:50 zakim, ??P30 is richard 16:01:50 +richard; got it 16:01:58 zakim, who's on the phone? 16:01:59 On the phone I see Ht, Jeni (muted), ??P10, [IPcaller], Norm, richard 16:02:02 +[ArborText] 16:02:29 zakim, IPcaller is rlopes 16:02:30 +rlopes; got it 16:02:37 zakim, ??P10 is Alessandro 16:02:37 +Alessandro; got it 16:02:40 zakim, who's on the phone? 16:02:40 On the phone I see Ht, Jeni (muted), Alessandro, rlopes, Norm, richard, PGrosso 16:02:59 +[IPcaller] 16:03:10 zakim, IPCaller is ebruchez 16:03:10 +ebruchez; got it 16:03:45 zakim, who's here? 16:03:45 On the phone I see Ht, Jeni (muted), Alessandro, rlopes (muted), Norm, richard, PGrosso, ebruchez 16:03:47 On IRC I see PGrosso, ebruchez, richard, Jeni, rlopes, Alessandro, RRSAgent, Zakim, Norm, ht, MSM 16:05:08 AndrewF has joined #xproc 16:05:30 +Alex_Milowski 16:05:36 +??P65 16:05:47 zakim, ??P65 is Andrew 16:05:47 +Andrew; got it 16:06:04 alexmilowski has joined #xproc 16:06:21 Present: Henry, Richard, Rui, Erik, Alessandro, Norm, Jeni, Paul, Andrew, Alex 16:06:31 Regrets: Robin, Michael (partial) 16:06:36 zakim, next agendum 16:06:36 agendum 1. "Administrivia" taken up [from Norm] 16:06:46 Accept this agenda? 16:06:47 Accepted. 16:07:04 Accept last week's minutes: http://www.w3.org/XML/XProc/2006/01/05-minutes.html 16:07:06 Accepted. 16:08:20 Norm reminds the group about the plenary and the hotel arrangements 16:08:25 zakim, next agendum 16:08:25 agendum 2. "Technical: email followup" taken up [from Norm] 16:08:57 Kinds of iteration? 16:09:34 Alex: we're getting more technical, are we start doing that now are we going to lose the requirements/use-cases thread? 16:10:51 Alex: The question of what passes between processes is an important one at this stage. 16:11:33 Alex: Core WG said "infosets" but now we need to support XDM and other augmented forms 16:12:31 Norm: the ability to pass around infosets and augmented infosets are both requirements in my mind 16:12:43 Jeni: I think there's a community that just wants to pass serialized XML around 16:13:11 Jeni: We ought to have a should or maybe requirement around those ideas 16:13:19 Richard: How is that different from an infoset? 16:13:44 Jeni: I think some folks care about whether things are represented by an entity or a Unicode character 16:13:57 Richard: So you're assuming the components aren't normal XML processors? 16:14:54 Jeni: The kind of pipeline I have in mind is one where someone takes a non well-formed XML document, smartens it up into XML, and then can report that as parsed XML to the next stage. Then later on, create some XML that is just a stream of characters (e.g., change particular characters into images) 16:15:03 Richard: So you'd be able to pass things around that aren't really XML? 16:15:23 Jeni: From my use cases, I think processes should be able to consume and produce things which aren't XML (especially HTML) 16:15:40 Jeni: Taking non-XML and turning it into XML is important. 16:16:10 Alex: Maybe we'll have to look at serialization more closely. 16:17:00 Alex: Maybe some of the other things should be doable on the end of a pipeline. 16:17:40 zakim, please call Michael-Office 16:17:40 ok, MSM; the call is being made 16:17:42 +Michael 16:17:48 Zakim, please unmute me 16:17:48 rlopes should no longer be muted 16:18:00 ack ebruchez 16:18:04 zakim, please mute Michael 16:18:04 Michael should now be muted 16:18:27 Norm: I imagined non-XML only at the ends but there's nothing that would prevent someone from glueing several together I suppose. 16:18:45 Erik: Talking about non-XML stuff is a little scary because it's more like Unix pipes and is a little more complex. We need to be careful. 16:19:15 Erik: Certainly it's important to some people to have some things, like entities, preserved, but if none of the existing data models do that, we should investigage why. 16:20:42 Erik: In XPL, we only deal with XML infosets. If a component is trying to read data which is not XML, then either the component access the information externally (not through a connection in the pipeline) or you can encapsulate the information in some XML format (e.g., base64 encoded) 16:20:53 s/access/accesses/ 16:21:26 Alex: We need to be very careful not to try to take on more than we can handle 16:22:23 Norm: Jeni only said "could" or "should". Let's see if we can get a better handle on the issues when we have more information (later in the process) 16:22:54 Richard: If we're dealing with both plain infosets and augmented infosets, then we could have an "unintepreted text" mode as well. Though we wouldn't have any standard components that work on them. 16:23:17 q? 16:23:23 ack rlopes 16:23:38 Rui: We can look at the way cocoon handles this issue 16:24:16 Erik: Cocoon handles this by using generators or serializers following a model similar to what I said about XPL above. 16:25:23 zakim, agenda? 16:25:23 I see 2 items remaining on the agenda: 16:25:24 2. Technical: email followup [from Norm] 16:25:25 3. Requirements [from Norm] 16:25:29 zakim, next agendum 16:25:29 agendum 3. "Requirements" taken up [from Norm] 16:26:11 Alex: I got as far as getting myself setup with XML Spec. I haven't done any new content, but I have a proposal about how it should be laid out. 16:26:43 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jan/0041.html 16:26:52 Alex: I'd like feedback on that layout before I proceed. 16:27:10 Alex: Do we need a terminology section? 16:27:51 Alex: There's a lot of terminology out there, we should define what we mean by things so that we don't confuse readers. 16:28:56 Alex: The previous document had a section on "design principles" but those sound like "requirements" to me. 16:29:23 Alex: I think we could introduce the idea that "design principles" are just very broad requirements. 16:30:37 q+ 16:30:55 ack MSM 16:31:05 ack MSM 16:31:09 zakim, unmute msm 16:31:09 sorry, Norm, I do not see a party named 'msm' 16:31:14 zakim, unmute MSM 16:31:14 sorry, Norm, I do not see a party named 'MSM' 16:31:16 hmm 16:31:17 zakim, please unmute Michael 16:31:17 Michael should no longer be muted 16:31:27 zakim, Michael is MSM 16:31:27 +MSM; got it 16:32:23 MSM: Design principles are not simply broad requirements in the following way: there have been some people active in W3C WGs who have said a "requirement" is (a) a crisp, verifiable statement and (b) is a do-or-die thing; if you don't meet the requirements you don't ship. 16:32:56 MSM: For people who take that view, keep it "short and simple" isn't crisp enough. Short you could manage, but "crisp" would be untestable. 16:33:23 MSM: But equally, it's not exactly a do-or-die situation. If you set a target of 20 pages and the normative prose turns out to be 21 pages, you typically call that a success. 16:33:56 MSM: If no one in our readership is going to interpret requirement as above, then Alex's proposal is fine. But there are those people in the world. 16:34:22 Alex: In that case, I would put "we process infosets" as a hard requirement. 16:34:45 +1 16:35:08 Norm: Does that all sound ok to folks then? 16:35:19 Yes. 16:38:20 Discussion of requirements in Alex's document 16:38:45 URL? 16:38:46 what is the URL of the document we're looking at? 16:38:49 Uhm 16:38:58 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jan/0041.html 16:39:37 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jan/att-0041/xproc-requirements.html 16:39:57 1. The language must be rich enough to address practical interoperability concerns. 16:40:14 Design principle 16:40:23 2. The language should be as small and simple as possible. 16:40:33 Design principle 16:40:39 3. The language must allow the inputs, outputs, and other parameters of a components to be specified. 16:40:51 Requirement. 16:40:56 4. he language must define the basic minimal set of mandatory input processing options and associated error reporting options required to achieve interoperability. 16:41:19 There's some confusion about this one 16:41:41 Editor will refactor. 16:42:33 5. Given a set of components and a set of documents, the language must allow the order of processing to be specified. 16:42:49 -richard 16:43:15 Requirement. 16:43:17 +??P28 16:43:22 zakim, ??P28 is richard 16:43:22 +richard; got it 16:43:43 6. # 16:43:43 It should be relatively easy to implement a conformant implementation of the language, but it should also be possible to build a sophisticated implementation that can perform parallel operations, lazy or greedy processing, and other optimizations. 16:43:43 # 16:44:18 Confusion? Design principles or requirements? 16:44:22 Editor will refactor. 16:44:41 7. The model should be extensible enough so that applications can define new processes and make them a component in a pipeline. 16:44:56 Requirement. 16:45:43 Richard: I think we should be careful not to use "extensibility" and "interoperability" without being fairly precise about what we mean. 16:46:11 8. The model must provide mechanisms for addressing error handling and fallback behaviors. 16:46:36 Requirement. 16:47:07 MSM: Are we talking about candidate requirements or requirements we've accepted 16:47:13 these are all "candidate" requirements at this stage, surely 16:48:40 Norm: I think we get to start over and we get to pick if these are requirements we accept or not after we believe we have a common understanding of what they mean 16:48:50 9. The model could allow conditional processing so that different components are selected depending on run-time evaluation. 16:49:04 MSM: Run-time evaluation is clear enough to count as crisp? 16:49:13 Alex: No, I think these will all get longer. 16:49:16 Requirement. 16:49:27 10. The model should not prohibit the existence of streaming pipelines. 16:49:31 Requirement. 16:50:02 Richard: we should be clear that you should be able to write pipelines that can be streamed rather than that every pipeline must be streamable. 16:50:13 Richard: Some things that you might want to do with pipelines cannot be streamed. 16:50:55 MSM: Can we imagine an option where I ask if this pipeline is streamable and fail if it isn't? 16:51:33 Erik: I'm not sure I understand the question. Should you have an option to ask the pipeline engine if a pipeline is streamable? 16:52:10 MSM: I would like the option of having the processor tell me if I've failed to write a streaming pipeline. 16:52:25 Erik: This sounds like something specific to a particular implementation. 16:52:33 MSM: It may be infeasable in general. 16:52:59 Erik: The idea is to leave the door open to allow some processors to optimize something to be streaming. 16:53:44 MSM: If it's that difficult to tell, then I'm concerned about it being a requirement as opposed to a design goal. 16:54:32 Richard: Something like a general XSLT transformation cannot possibly be guaranteed to be streamble. There are some cases where the streambility is determined by the compoents. 16:55:16 Richard: But if there are conditionals in the language then it may also not be possible to stream on that basis (.e.g, a condition that cannot be deterined until some stage has finished). 16:55:16 Richard: As we proceed through, we shouldn't put anything in that prevents a streaming pipeline. 16:55:32 Alex; We can mark this as a possible new requirement and debate it as we proceed. 16:55:47 I I think that's too specific of a reuirement 16:56:26 I am having trouble imagining a language construct that would not only be non-streamable but would successfully prohibit the writing of streamable pipelines. Is the req as formulated by Core a nop? 16:56:43 11. # 16:56:43 The model should allow multiple inputs and multiple outputs for a component. 16:56:43 # 16:57:03 Requirement. 16:57:03 12. The model should allow any data set conforming to one of the W3C standards, such as XML 1.1, XSLT 1.0, XML Query 1.0, etc., to be specified as an input or output of a component. 16:57:47 I'd be inclined to state it broadly as a design principle. 16:58:14 Michael - a rule that downstream components must not start unless it is guaranteed that no upstream component will abortld be an example of such a construct 16:58:42 Alex: That boils down to specific ones for known languages. 16:59:13 Norm: I think we may be able to answer the question more generally, but I'm ok with that. 16:59:24 13. Information should be passed between components in a standard way, for example, as one of the data sets conforming to an industry standard. 16:59:36 Richard: I think that means it should use things like SAX and DOM 16:59:49 MSM: Except that neither SAX nor DOM is a data set. 17:00:14 Alex: we could refactor that to say that we don't want to preclude ... some list of known ways to pass infosets. 17:00:43 Richard: The Core WG may have been trying to express that it didn't want us to invent a *new* way 17:01:00 Richard: The fact that the Core WG included it doesn't mean everyone there agreed with it. 17:01:20 Editor will refactor. 17:01:37 14. The language should be expressed in XML. It should be possible to author and manipulate documents expressed in the pipeline language using standard XML tools. 17:01:52 Requirement. 17:02:07 15. The pipeline language should be declarative, not based on APIs. 17:03:04 Erik: I would argue that XPL is declarative 17:03:28 Erik: You really are declaring linking of components together and leaving it to the implementation to do the work 17:03:57 Richard: The idea here is that the language for expressing the connections between components should be declarative. 17:04:32 16. The model should be neutral with respect to implementation language. 17:05:22 Requirement. 17:05:49 Norm: Do you have enough to make a first pass? 17:06:05 Alex: Yes. If you look at this list and see things missing, we should add them. 17:06:47 Alex: I'll take a first stab at it from the minutes of the preceding meetings. 17:07:50 -Alessandro 17:07:51 ACTION: Alex to produce document by c.o.b. 17 Jan 2006 17:07:51 -richard 17:07:53 -Andrew 17:07:54 -ebruchez 17:07:55 -Alex_Milowski 17:07:56 -PGrosso 17:07:57 alexmilowski has left #xproc 17:07:57 -Norm 17:07:58 -rlopes 17:08:00 -Ht 17:08:01 ADJOURNED 17:08:01 -Jeni 17:08:03 -MSM 17:08:03 PGrosso has left #xproc 17:08:04 XML_PMWG()11:00AM has ended 17:08:05 Attendees were Ht, Jeni, Norm, richard, PGrosso, rlopes, Alessandro, ebruchez, Alex_Milowski, Andrew, MSM 17:08:10 rrsagent, make draft minutes 17:08:10 I'm logging. I don't understand 'make draft minutes', Norm. Try /msg RRSAgent help 17:09:07 rrsagent, draft minutes 17:09:07 I have made the request to generate http://www.w3.org/2006/01/12-xproc-minutes.html Norm 17:09:09 Alessandro has left #xproc 17:09:15 rrsagent, set logs world-visible 17:27:49 zakim, bye 17:27:49 Zakim has left #xproc 17:27:51 rrsagent, bye 17:27:51 I see 1 open action item saved in http://www.w3.org/2006/01/12-xproc-actions.rdf : 17:27:51 ACTION: Alex to produce document by c.o.b. 17 Jan 2006 [1] 17:27:51 recorded in http://www.w3.org/2006/01/12-xproc-irc#T17-07-51