15:33:50 <RRSAgent> RRSAgent has joined #xproc
15:33:50 <RRSAgent> logging to http://www.w3.org/2006/01/19-xproc-irc
15:33:54 <Norm> zakim, this will be xproc
15:33:54 <Zakim> ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 27 minutes
15:46:51 <Norm> zakim, agenda+ Administrivia
15:46:51 <Zakim> agendum 1 added
15:46:57 <Norm> zakim, agenda+ Requirements and Use Cases
15:46:57 <Zakim> agendum 2 added
15:47:09 <Norm> zakim, agenda+ Any other business
15:47:09 <Zakim> agendum 3 added
15:47:27 <Norm> Meeting: XML Processing Model WG
15:47:27 <Norm> Scribe: Norman Walsh
15:47:27 <Norm> ScribeNick: Norm
15:47:27 <Norm> Date: 19 Jan 2005
15:47:27 <Norm> Chair: Norm
15:47:28 <Norm> Agenda: http://www.w3.org/XML/XProc/2006/01/19-agenda.html
15:56:41 <PGrosso> PGrosso has joined #xproc
15:56:53 <rlopes> rlopes has joined #xproc
15:58:50 <Alessandro> Alessandro has joined #xproc
15:59:05 <Zakim> XML_PMWG()11:00AM has now started
15:59:12 <Zakim> +Norm
15:59:14 <Zakim> +[IPcaller]
15:59:24 <Norm> zakim, IPcaller is rlopes 
15:59:26 <Zakim> +rlopes; got it
15:59:43 <Zakim> +Alessandro_Vernet
16:00:31 <alexmilowski> alexmilowski has joined #xproc
16:00:39 <ht> zakim, please call ht-781
16:00:39 <Zakim> ok, ht; the call is being made
16:00:43 <Zakim> +Ht
16:00:47 <Zakim> +[ArborText]
16:01:27 <Norm> zakim, who's on the phone?
16:01:30 <Zakim> On the phone I see rlopes, Norm, Alessandro_Vernet, Ht, PGrosso
16:01:34 <Zakim> +Alex_Milowski
16:01:52 <AndrewF> AndrewF has joined #xproc
16:02:22 <Zakim> +??P53
16:02:41 <AndrewF> zakim, ??p53 is andrewF
16:02:41 <Zakim> +andrewF; got it
16:03:46 <richard> richard has joined #xproc
16:04:08 <ebruchez> ebruchez has joined #xproc
16:04:16 <Zakim> +??P8
16:04:22 <richard> zakim, ? is richard
16:04:22 <Zakim> +richard; got it
16:05:50 <Norm> Present: Norm, Rui, Alessandro, Henry, Paul, Andrew, Richard
16:06:03 <Norm> Present: Norm, Rui, Alessandro, Henry, Paul, Andrew, Richard, Alex
16:06:09 <Norm> Regrets: Jeni
16:06:23 <Zakim> +[IPcaller]
16:06:25 <Zakim> -rlopes
16:06:33 <Zakim> +[IPcaller.a]
16:06:34 <Norm> Present: Norm, Rui, Alessandro, Henry, Paul, Andrew, Richard, Alex, Erik
16:06:58 <Norm> zakim, IPcaller is ebruchez 
16:06:58 <Zakim> +ebruchez; got it
16:06:58 <Norm> zakim, IPcaller.a is rlopes 
16:06:59 <Norm> zakim, next agendum
16:06:59 <Zakim> +rlopes; got it
16:07:01 <Zakim> agendum 1. "Administrivia" taken up [from Norm]
16:07:07 <Norm> Topic: accept this agenda?
16:07:07 <Norm> -> http://www.w3.org/XML/XProc/2006/01/19-agenda.html
16:07:12 <Norm> Accepted.
16:07:16 <Norm> Topic: accept minutes from the previous teleconference?
16:07:16 <Norm> -> http://www.w3.org/XML/XProc/2006/01/12-minutes.html
16:07:23 <Norm> Accepted.
16:07:30 <Norm> Topic: next meeting: 26 Jan 2006.
16:07:30 <Norm> Any regrets?
16:07:47 <Norm> Possible regrets from Norm
16:08:12 <Norm> Henry to chair in Norm's absence
16:08:17 <Norm> Topic: Tech Plenary
16:08:17 <Norm> Registration is now open; discounted rates at the Sofitel end tomorrow
16:08:43 <Norm> zakim, next agendum
16:08:44 <Zakim> agendum 2. "Requirements and Use Cases" taken up [from Norm]
16:09:13 <PGrosso> http://www.w3.org/2005/12/allgroupoverview.html
16:09:23 <Norm> Thank you, Alex
16:10:51 <Norm> Alex: Some consolidation needed on the use cases; they aren't tightly coupled with the requirements yet
16:10:57 <Norm> Alex: Many use cases contain the same components.
16:11:10 <Norm> Alex: It might be a good idea to factor out the common bits
16:12:01 <Norm> Norm: Was lack of discussion about PSVI in "Infoset Processing" intentional?
16:12:09 <Norm> Alex: It does say augment...
16:12:40 <Norm> Norm suggests "Infoset, augmented infoset, or other data models"
16:12:53 <Norm> Erik: Is there agreement already that the infoset is our minimum?
16:12:59 <richard> richard has joined #xproc
16:13:04 <Norm> Alex: From an XML perspective, that seems right
16:13:25 <Norm> Norm: Erik, did you have something else in mind?
16:13:31 <Norm> Erik: No, that's fine 
16:14:22 <Norm> Alex: Augmenting or annotation infosets is something I've always imagined a pipeline language could support
16:16:09 <Norm> Norm points out some ways that XDM is different from Infoset.
16:16:27 <Norm> Erik: can you consider the XDM as a superset of the Infoset?
16:16:55 <Norm> Richard: It's not a subset or superset but it has a correspondence
16:18:13 <Norm> Some discussion of XDM follows.
16:18:36 <Norm> Richard: I'm worried that we're trying to include too many things. We should concentrate first and formost on infosets and anything else should be an extension
16:19:18 <Norm> Erik: I'm inclined to agree, but we have also had mail that suggests we need to support some things that aren't infosets (documents containing only text nodes, etc.)
16:19:33 <Norm> Erik: The best place to look if we need to do those things may be XDM.
16:19:52 <Norm> Erik: Rather than specifying our own thing, we should point to XDM.
16:20:40 <Norm> Erik: This might also make it easier to deal with parameters as they could be the XDM instances from some previous process
16:21:29 <Norm> Alex: I can see the advantage of XDM, but there are lots of simple pipelines that don't require that
16:22:20 <Norm> Richard: I assume at this stage we aren't planning to standardize the representation of XDM. One way to do this is to say that you pass infosets or extended infosets and anything you want to pass like XDMs, you represent them as extended infosets
16:22:47 <Norm> Norm: that appeals to me
16:23:03 <alexmilowski> How about: "At minimum, an XML document is represented and manipulated as an information set.  Use of a super-set, augmented or extended information sets, or data models that map to information should be allow be implementations."
16:23:32 <Norm> s/information/information set/
16:23:53 <Zakim> +Michael
16:25:15 <Norm> Erik: this is a minimal goal; we may come back to this later
16:26:22 <Norm> Richard: I think that saying things like XDM are represented as extended infosets at least gives us a handle on what kinds of things can be in components
16:28:05 <Norm> Richard: I'd like to say that what passes between components are infosets, possibly augmented
16:28:29 <MSM> MSM has changed the topic to: XProc WG: http://www.w3.org/XML/XProc/2006/01/19-agenda.htmlq+
16:28:38 <MSM> MSM has changed the topic to: XProc WG: http://www.w3.org/XML/XProc/2006/01/19-agenda.html
16:28:41 <MSM> q+
16:29:41 <MSM> q+ to express uneasiness about the phrase "represented as" followed by the phrase "an infoset".  Infosets are way too abstract to serve as representations in any useful way - they aren't APIs or data structures
16:30:30 <Norm> Erik: I think one thing we are trying to say is that this is a minimum requirement. The model must support passing infosets between components. If an implementation wants to say that it supports passing things from XDM, maybe we should try to allow this. 
16:30:47 <Norm> Richard: I did not intend to allow you to pass a sequence of integers between components
16:31:11 <Norm> I want extensions such as that to be outside the scope of what we are standardizing.
16:31:26 <Norm> s/I want/Richard: I want/
16:31:51 <Norm> q?
16:32:17 <Norm> Erik: XDM is an XML Data Model and it does allow more things
16:34:40 <Norm> ack msm
16:34:40 <Zakim> MSM, you wanted to express uneasiness about the phrase "represented as" followed by the phrase "an infoset".  Infosets are way too abstract to serve as representations in any
16:34:44 <Zakim> ... useful way - they aren't APIs or data structures
16:35:29 <Norm> MSM: Richard made me very nervous by speaking about data models "represented as" infosets. It suggests that infosets are APIs or data structures and I think they are neither. They are more abstract. 
16:35:39 <Norm> Richard: I understand your reservation and I agree essentially. 
16:36:27 <Norm> Richard: I certainly wasn't implying anything about an API; I simply wanted to constrain things sufficiently such that we could speak of passing information items around rather than talking about integers and sequences.
16:36:51 <Norm> MSM: I think that can be paraphrased as "data models conceptualized as infosets" and I'm happy with that.
16:37:28 <richard> i am happy with "conceptualized as" rather than "represented as"
16:37:47 <Norm> Norm: Any other concerns about design principles?
16:38:00 <Norm> Moving on to terminology...
16:38:45 <Norm> Alex: I tried to factor out the the distinction between straight-through processing as pipelines and process models which may be more complex.
16:38:52 <Norm> Alex: Those are both really the subject of our spec.
16:39:11 <Norm> Henry: I don't find this helpful. It's useful to get started on iterating over this.
16:39:35 <Norm> Henry: I don't think restricting pipeline to "straight through" is very clear or likely to work for this group.
16:39:46 <Norm> Henry: I agree the distinction is important, but I'd rather not do it this way.
16:40:17 <Norm> Richard: I partly agree with Henry because I think "process model" is probably interpreted as a more general term and includes descriptions of how they are processed that doesn't include things that we're going to describe.
16:40:32 <Norm> Norm: I concur
16:40:57 <Norm> Alex: Maybe we could define one and then I could take a pass through to use that term consistently.
16:41:35 <Norm> Norm: I think of the pipeline as the whole thing
16:41:56 <ht> HST likes 'XML Pipeline' for the whole space, 'pipeline language' for AM's 'specification language' and 'pipeline document' for an XML document in a pipeline language
16:42:07 <Norm> Richard: I see pipeline conceptually as the flow of a document through a series of components. They aren't linear.
16:42:58 <Norm> Erik: If we do use the term "pipeline", I'd like that to mean the whole thing.
16:43:32 <ht> +1 -- A pipeline is a configuration of steps, steps involve components and connectivity and parameters
16:44:37 <Norm> Henry: I like "pipeline" for the whole thing that documents pass through, I like "pipeline document" to describe a document in a "pipeline language". Pipelines have "steps" which consist of "a component" plus it's parameters and connectivity.
16:44:56 <Norm> Alex: I don't like the term "process model". So I'm happy to consolidate these things into "pipeline"
16:46:08 <Norm> Richard: A step can be used in isolation, but when you specify what a unix program does, you specify what it's stardard input/output/error and parameters are and that seems to be consistent with "component"
16:46:17 <Norm> s/stardard/standard/
16:46:44 <Norm> Erik: A component could be XSLT or XQuery, but a step is an instance of one of those things.
16:47:03 <Norm> Richard: I agree that a step is an instance of a component with various things associated with it.
16:47:32 <Norm> Erik: "Step" has a strongly linear connotation, but we might have things in parallel or conditional.
16:47:53 <Norm> Richard: Yes, but it is used in descriptions of programming languages and that covers the parallel case for me.
16:48:16 <Norm> Alex: Maybe we can take a stab at defining "pipeline" and "step" to replace process model.
16:48:25 <Norm> Alex proposed something the scribe failed to capture
16:49:12 <alexmilowski> A pipeline is a configuration of steps that defines, but not limited to, order, dependencies, or iteration along with their configuration.
16:49:51 <Norm> Norm asks about the term "component vocabulary"
16:51:04 <Norm> Some discussion follows
16:51:31 <ebruchez> We've used the term "interface" to describe how a component communicates with the rest of the pipeline
16:53:13 <Norm> Alex: when I say vocabulary, I actually mean an XML language (a set of XML elements)
16:54:52 <Norm> Richard: I think what Erik described as an interface is what I described as a "component specification": the thing that a generic pipeline editor would need to have
16:55:09 <Norm> ...to allow you to join components together
16:56:13 <Norm> Alex: maybe we could consolidate "use environment" and "binding"?
16:56:21 <Norm> Alex: there's a whole context in which a pipeline runs.
16:56:48 <Norm> Richard: I think "environment" is quite widely used. Binding seems more specific.
16:57:02 <Norm> Alex: Maybe we could use "pipeline environment"
16:57:04 <Norm> Norm: Yes.
16:57:36 <Norm> Alex: I suggest that people send feedback by email. The two most critical bits are: which things should be combined or refactored and the connections between requirements and use cases.
16:58:06 <richard> The great thing about the term "pipeline" is the associated plumbing metaphor - sources, sinks, the ability to insert Ts and so on
16:58:29 <Norm> Alex: I'll shoot for another draft on Tuesday.
16:59:23 <Norm> zakim, next agendum
16:59:23 <Zakim> agendum 3. "Any other business" taken up [from Norm]
17:00:52 <Norm> If you're going to be at the f2f, please describe your conflicts for Monday/Tuesday by email.
17:01:16 <Norm> If you're not going to the f2f, please indicate if you'd like to dail in for all or part of our meetings. Taking into account the time of day in your part of the world :-)
17:01:43 <Zakim> -ebruchez
17:01:44 <Norm> ADJOURNED
17:01:44 <Zakim> -Norm
17:01:45 <Zakim> -Ht
17:01:47 <Zakim> -richard
17:01:48 <Zakim> -andrewF
17:01:49 <Zakim> -PGrosso
17:01:50 <Zakim> -Alex_Milowski
17:01:50 <PGrosso> PGrosso has left #xproc
17:01:51 <Zakim> -Alessandro_Vernet
17:01:53 <alexmilowski> alexmilowski has left #xproc
17:01:53 <Zakim> -rlopes
17:01:53 <Zakim> -Michael
17:01:53 <Norm> rrsagent, make logs world-accessible
17:01:54 <Zakim> XML_PMWG()11:00AM has ended
17:01:56 <Zakim> Attendees were Norm, rlopes, Alessandro_Vernet, Ht, PGrosso, Alex_Milowski, andrewF, richard, ebruchez, Michael
17:02:00 <Norm> rrsagent, make logs public
17:02:09 <Norm> rrsagent, draft minutes
17:02:09 <RRSAgent> I have made the request to generate http://www.w3.org/2006/01/19-xproc-minutes.html Norm
17:11:25 <Norm> zakim, bye
17:11:25 <Zakim> Zakim has left #xproc
17:11:25 <Norm> rrsagent, bye
17:11:25 <RRSAgent> I see no action items