15:34:13 <RRSAgent> RRSAgent has joined #xproc
15:34:13 <RRSAgent> logging to http://www.w3.org/2007/02/15-xproc-irc
15:34:35 <Norm> Meeting: XML Processing Model WG
15:34:35 <Norm> Date: 15 Feb 2007
15:34:35 <Norm> Agenda: http://www.w3.org/XML/XProc/2007/02/15-agenda.html
15:34:35 <Norm> Meeting number: 55, T-minus 37 weeks
15:34:35 <Norm> Chair: Norm
15:34:36 <Norm> Scribe: Norm
15:34:38 <Norm> ScribeNick: Norm
15:37:07 <MoZ> AllMighty: Norm
15:57:05 <PGrosso> PGrosso has joined #xproc
15:59:28 <Norm> Regregs: Alessandro
15:59:33 <Norm> Regrets: Alessandro
16:00:36 <ht> zakim, please call ht-781
16:00:44 <Zakim> ok, ht; the call is being made
16:00:46 <Zakim> XML_PMWG()11:00AM has now started
16:00:50 <Zakim> +Ht
16:01:03 <Zakim> +[ArborText]
16:01:18 <Zakim> +Norm
16:03:19 <Norm> zakim, who's on the phone?
16:03:19 <Zakim> On the phone I see Ht, PGrosso, Norm
16:03:38 <Zakim> +Murray_Maloney
16:04:27 <richard> richard has joined #xproc
16:04:38 <richard> i'll be on in a couple of minutes
16:04:52 <alexmilowski> alexmilowski has joined #xproc
16:05:36 <Zakim> +Alex_Milowski
16:05:40 <Norm> zakim, who's here?
16:05:40 <Zakim> On the phone I see Ht, PGrosso, Norm, Murray_Maloney, Alex_Milowski
16:05:41 <Zakim> On IRC I see alexmilowski, richard, PGrosso, RRSAgent, Zakim, MoZ, MSM, Norm, ht
16:07:12 <Zakim> +MoZ
16:07:17 <Norm> Present: Henry, Paul, Norm, Murray, Alex, Mohamed
16:07:40 <Norm> Topic: Accept this agenda?
16:07:40 <Norm> -> http://www.w3.org/XML/XProc/2007/02/15-agenda.html
16:07:46 <Norm> Accepted.
16:07:50 <Norm> Topic: Accept minutes from the previous meeting?
16:07:51 <Norm> -> http://www.w3.org/XML/XProc/2007/02/08-minutes.html
16:07:57 <Norm> Accepted.
16:08:01 <Norm> Topic: Next meeting: telcon 22 Feb 2007
16:08:01 <Zakim> +??P15
16:08:04 <richard> zakim, ? is me
16:08:04 <Zakim> +richard; got it
16:08:13 <Norm> Present: Henry, Paul, Norm, Murray, Alex, Mohamed, Richard
16:08:19 <Norm> Regrets from Paul.
16:08:37 <Norm> Topic: Face-to-face in 2007? Meeting at the plenary in November?
16:09:49 <MSM> zakim, please call MSM-Office
16:09:49 <Zakim> ok, MSM; the call is being made
16:09:49 <Norm> Still no progress. Norm notes that the Charter expires before November.
16:09:51 <Zakim> +MSM
16:10:00 <Norm> Henry: I think saying "yes" now is important even if the answer is only maybe.
16:10:09 <Norm> Norm: I'm going to say "yes"
16:10:41 <Norm> Norm: We can decide if we really have critical mass, and an extended charter, a little closer and back out if necessary.
16:11:11 <Norm> Norm: Sonoa systems hasn't shown up in ages and can't be reached anymore, can we please declare them no longer in good standing?
16:11:24 <Norm> Paul: You're supposed to contact the AC rep.
16:11:28 <Norm> Henry: He is the AC rep.
16:12:06 <Norm> ACTION: Henry: mark Sonoa system as no longer in good standing.
16:12:30 <Norm> Topic: Chameleon components: p:step vs. p:xslt
16:13:05 <Norm> -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0049.html
16:14:40 <Norm> Norm attempts to describe the thread
16:15:02 <Norm> Richard: I haven't thought much about this.
16:15:07 <MSM> q+ to ask how validation is trickier with just one GI; validation seems easier to me with distinct GIs
16:15:40 <Norm> Richard: Aren't namespaces supposed to handle this? We could use parameters in the XProc namespace and the fact that you couldn't pass those to the stylesheet appears negligible.
16:15:47 <Norm> ack msm
16:15:47 <Zakim> MSM, you wanted to ask how validation is trickier with just one GI; validation seems easier to me with distinct GIs
16:16:41 <Norm> MSM: How is validation harder? We could do what Richard says and still pass them to the process. You just wouldn't be able to have different values for them.
16:17:19 <MSM> pipeline ::= (step | #any)*
16:17:53 <MSM> allows anything that matches the wildcard to be ignored.
16:18:10 <ht> Subst group is the XML Schema technology
16:18:36 <Norm> Norm attempts to describe what he recalls at Murray's place. Mostly, I think we just didn't think about it hard enough.
16:19:06 <Norm> Alex: The hardest part is that if you say your environment must validate before compiling a pipeline then the user will have to augment the schema if they add a new component type.
16:19:20 <Norm> Norm: Yeah, but presumably that's a quality of implementation issue.
16:19:22 <MSM> <xsd:schema><xsd:element name="mycomponent" susbtitutionGroup="p:step"/></xsd:schema>
16:19:30 <Norm> Alex: Yes, but we're putting that one small barrier there.
16:19:50 <MSM> [A one-liner is really all you need.  I agree with AM that we should consider it, but I think it's easy enough.]
16:20:55 <Norm> Henry: I find this a difficult call. I think the crucial difference is that you can do this with schema languages using the relevant mechanisms.
16:21:10 <Norm> ...But in all three cases, if we go this route, you must do that or your document isn't valid if you've added new components.
16:21:25 <MSM> Henry, what role do you expect the notion of 'validity' to play?
16:21:28 <Norm> ...Whereas if we go with the status quo, then your document is valid. You don't have to do anything, the published schemas will validate your pipeline.
16:21:33 <alexmilowski> q+
16:22:14 <Norm> Henry: That's just a fact, but I don't know if it matters. My inclination is to favor the change because if it means that people who utter extensions will have to get the framework right.
16:22:34 <richard> q+
16:22:35 <Norm> ...If you have to use Widgets, Inc.'s schema in order to use their extensions, then that's a good consistency check.
16:22:47 <Norm> ...That tends me to think that it's a good idea.
16:23:02 <MSM> q+ to ask what a pipeline processor should normally do with  <p:pipeline><p:step .../><my:element .../></p:pipeline>
16:23:03 <Norm> s/tends me to/tends to make me/
16:23:11 <Norm> ack alexmilowski 
16:23:23 <Norm> Alex: I'm really in favor of this, but I still want to poke holes in it.
16:23:39 <Norm> ...We've said that we want our language to be open, so you can add documention, etc.
16:23:55 <Norm> ...That means that these things would be wildcards and that makes steps that are extensions would just be passed off as things that wouldn't be validated.
16:24:25 <Norm> Henry: I don't want to go that route. I tend to think of it in terms of substitution groups. They only way you can do this is by identifying the abstract p:step as the substitution group head.
16:24:41 <Norm> Alex: That means that we have to come up with some other mechanism to embed documentation.
16:25:17 <Norm> Henry: Extension elements have no semantics. We said in the schema design that you can sprinkle elements and attributes to your hearts content but they have no impact on the validation semantics.
16:25:19 <MSM> q+ murray
16:25:27 <Norm> ack richard 
16:25:51 <Norm> Richard: I think this is a complete red herring. No one's going to validate them, they're just going to run them through a pipeline processor and get better messages that way.
16:25:55 <Norm> ack msm
16:25:55 <Zakim> MSM, you wanted to ask what a pipeline processor should normally do with  <p:pipeline><p:step .../><my:element .../></p:pipeline>
16:25:56 <ht> q+ to disagree with richard
16:25:56 <alexmilowski> (yes... e.g. no one validates an XSLT transformation document)
16:26:45 <MoZ> q+ to give his two levels of disagreement on p:xslt
16:27:31 <alexmilowski> q+
16:27:34 <Norm> Michael: Our current design is that given a pipeline as above, my:element will be ignored.
16:27:34 <Norm> Norm: Yes.
16:27:34 <Norm> Michael: In that case, I don't think Henry quite answered Alex's question.
16:27:34 <Norm> ...If we're going to accept a pipeline like above, then I don't have to provide a substitution group to make the document valid.
16:27:36 <Norm> Henry: You're right.
16:27:40 <Norm> Henry: If you've failed to do so then nothing will happen.
16:27:44 <Norm> Michael: That depends purely on whether or not the pipeline processor uses the substitution group information.
16:28:26 <Norm> Michael: It's possible to write a processor such that it validates and then uses the PSVI information.
16:28:31 <Norm> Richard: That's an interoperability nightmare.
16:28:43 <Norm> Henry: We haven't tackled the question of how you make the syntax/semantics link for new steps.
16:29:36 <MSM> q+ to propose a strawman (? or real?) argument going the other way.
16:30:24 <Norm> ack murray
16:30:30 <Norm> Murray: This conversation is coming at weird angles for me.
16:30:38 <Norm> ...We have a mechanism for declaring steps, right?
16:30:47 <Norm> ...I would have thought that's were we'd be talking about this.
16:31:04 <richard> i agree with murray: we tell the pipeline about steps by declaring them, not by a schema
16:31:19 <Norm> ...If I want a my:foo then I'd have to declare it. I would have thought that it would be possible to read that and generate a bit of schema if you wanted to satisfy the validation.
16:31:29 <Norm> ...And you could not bother with the validation if you just didn't care.
16:31:42 <Norm> ...The implementation is going to get it's information about the step from that declaration.
16:31:49 <MSM> If an extension step is <p:step type="my:newstep" ... />, we can still get a validity story (for those who want to have one):  p:step/@type is typed union of p:built-ins, my:extensionsteps, xs:QName, xs:string; you can still use validation to tell whether your pipeline is going to be processed reliably.
16:32:12 <Norm> ack henry
16:32:16 <Norm> ack ht
16:32:16 <Zakim> ht, you wanted to disagree with richard
16:32:37 <Norm> Henry: I think you're right, but going a little further I'm still worried about the interoperability story in the non-chameleon case.
16:32:57 <Norm> ...Consider Michael's pipeline: <p:xslt>...</p:xslt><my:step>...</my:step>
16:33:23 <Norm> ...Now consider two impls: one produced by the owner of the my: namespace with the step declaration built in.
16:33:45 <Norm> ...Now consider Norm's impl. It doesn't have any builtin step definition for my:step so it ignores the my:stpe.
16:33:45 <richard> is it allowed for implementations to have extra built-in step types?  shouldn't you have to import a library to access them?
16:33:48 <Norm> s/stpe/step/
16:33:53 <MSM> Henry, what does the second implementation do with the declaration of my:step ?
16:34:02 <richard> bingo!
16:34:11 <Norm> Henry: I think that means you must declare every step that you use other than the ones in the spec.
16:34:54 <Norm> q?
16:35:37 <Norm> Henry: I wanted to remark that I disagree with Richard about the utility of validating without running. I often use validation on things I can't run as a first order check.
16:36:57 <Norm> ack MoZ 
16:36:57 <Zakim> MoZ, you wanted to give his two levels of disagreement on p:xslt
16:37:30 <Norm> Mohamed: I think the requirement of validation is a strong requirement. Authoring tools must follow a schema or something like that. We need to have a strong way to declare what is in the XProc definition at the start.
16:37:52 <MSM> [I suspect it might be a good idea to make a point of recording design principles we discover, such as "if a pipeline is not interoperable, then we must design the spec so that processors which cannot support it (a) can detect the fact that they don't support it and (b) must say so. "  If we have that written down, I don't know where.  If we don't, and agree on it, we should get it written down.]
16:38:09 <Norm> ...It must be clear. Effectively, one person's user define step could be taken as a special annotation. We can't have a fallback to not knowing what the user meant by that user-defined namespace.
16:38:18 <Norm> ...With the p:step the declaration of the name was an indication. 
16:38:38 <Norm> ...The content of the p:step was also defined. We knew what we would find in a step. In a my:component, I don't know what I'm going to find.
16:39:01 <Norm> Richard: That raises a good point. Suppose you write a schema for a pipeline that allows extra things. Presumably that's not going to work.
16:39:05 <ht> I can summarise the observation that Murray's point led me to as "Conformant processors MUST NOT treat elements not defined as steps in this specification as steps unless there is an _explicit_ define-step-type for it in the pipeline or in a library it includes"
16:39:20 <Norm> Mohamed: That's why I'm opposed to p:xslt and prefer p:step.
16:39:22 <Norm> q?
16:39:27 <Norm> ack alexmilowski 
16:39:47 <Norm> Alex: In the email thread, I said that we should identify extension namespaces (like XSLT)
16:40:15 <Norm> -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0055.html
16:40:30 <Norm> Alex: I'm not sure I want to require such an attribute, but it is a nice double check.
16:40:36 <MSM> [Alex, remember though that that feature in XSLT doesn't map to any existing schema language -- it requires some rather ad hoc checks.]
16:40:57 <ht> q+ to a) check what Richard/MoZ were saying and b) comment on AM's point
16:41:29 <Norm> Norm and Alex discuss the declaration vs. namespace aspect.
16:41:36 <richard> q+
16:41:46 <Norm> ack msm
16:41:46 <Zakim> MSM, you wanted to propose a strawman (? or real?) argument going the other way.
16:42:18 <ht> s/define-step-type/declare-step-type/
16:42:36 <Norm> Michael: I wanted to observe that if we want to have schema validity be a useful proxy for interoperably processable, then that doesn't actually cut the one direction.
16:43:03 <Norm> ...You can make a schema for p:step that would require extension steps to be declared, you could make one that allows them but recovers if they're not, etc.
16:43:42 <Norm> ...Specifically, if you wanted to be able to detect the presence of undeclared steps you could make the step's type attribute a union of the builtin names plus the names that get populated when the user writes an extension.
16:44:06 <Norm> q?
16:44:08 <Norm> ack ht
16:44:08 <Zakim> ht, you wanted to a) check what Richard/MoZ were saying and b) comment on AM's point
16:44:27 <Norm> Henry: I'm not sure I understood what Mohamed and Richard were saying.
16:44:59 <Norm> ...We don't have to require validation with a normative schema in order to use one to define the semantics and constraints.
16:45:01 <Zakim> -Ht
16:45:25 <Norm> ht, you got dropped!
16:45:30 <Norm> ack richard 
16:45:31 <Norm> q+ ht
16:45:31 <ht> zakim, please call ht-781
16:45:33 <Zakim> ok, ht; the call is being made
16:45:33 <PGrosso> PGrosso has joined #xproc
16:45:34 <Zakim> +Ht
16:46:00 <Norm> Richard: In the current system, if you misspell a step name then you get an error.
16:46:11 <alexmilowski> yes
16:46:14 <Norm> ...In the other system, if you misspell a step name, isn't it just ignored?
16:46:24 <Norm> ...If that's true then this seems to be really bad for error detection.
16:46:27 <alexmilowski> ...that is why I wanted that "extension namespace" declaration...
16:46:44 <Norm> Henry: I think that's a real issue.
16:47:09 <Norm> Richard: If we were to go for this then I think we'd have to have an extension namespaces element to declare the things that could be ignored if they were unknonwn.
16:47:11 <Norm> ack ht
16:47:35 <Norm> Henry: All I was trying to say was that if we don't require validation, we might still choose to use a schema to put conditions on acceptable input.
16:48:00 <Norm> ...If we do that then I think we can still say that every user defined step must have the following abstract content model.
16:48:28 <Norm> ...I don't think there's a vulnerability there to people smuggling in all sorts of nonsense.
16:48:49 <alexmilowski> q+
16:49:02 <Norm> ...I had hoped that the requirement for every step to have a declaration would be sufficient to ensure interoperability. But Richard is correct that it's not as robust with respect to spelling mistakes.
16:49:24 <MSM> [N.B. To protect against smuggling in arbitrary nonsense, the normative schema would need to block declaration or substitution of extensions to the step type.  Just using substitution groups doesn't give the protection HT was describing.]
16:49:31 <Norm> ...It seems to me that there are at least two ways to resolve that: one is to say that you have to declare the type and note that the namespace is an extension namespace.
16:50:06 <Norm> ...Another possibility which I think I might prefer is to say that you have to declare your ignore-me namespaces.
16:50:18 <Norm> Norm: Yes, I like that a little better.
16:50:18 <Norm> q?
16:50:22 <Norm> ack alexmilowski 
16:50:38 <Norm> Alex: Henry's last comment is exactly what I was going to say.
16:50:47 <Norm> q?
16:51:12 <Norm> zakim, who's on the phone?
16:51:12 <Zakim> On the phone I see Ht, PGrosso, Norm, Murray_Maloney, Alex_Milowski, MoZ, richard, MSM
16:51:45 <Norm> Straw poll: Shall we use the status quo of p:step type="p:xxx" or the proposed change to use p:xxx as the name of the element for the step.
16:51:52 <MSM> question: how is the type attribute declared / to be declared?
16:52:36 <MSM> or does that matter?  does the status quo specify?
16:53:53 <Norm> Results: four in favor of the change, three for the status quo, one abstention.
16:54:19 <Norm> Henry: The one thing I never said is that the change allows us to explore the use of attributes on these elements that would be a little odd otherwise.
16:54:48 <Norm> Paul: I didn't feel strongly.
16:54:52 <Norm> Richard: I didn't feel strongly either.
16:55:14 <Norm> Henry: Come back to this a week later?
16:55:19 <Norm> Alex: Maybe see some pipelines?
16:56:12 <MSM> give someone an action to summarize the question, the options, and the arguments each way 
16:56:15 <Norm> Richard: I think we've exposed a lot of the issues talking about it today.
16:56:32 <Norm> ...There isn't really very much to choose between them.
16:56:46 <Norm> Henry: I think we should take Alex's offer up.
16:56:52 <Norm> ...I'll try to recast some examples too.
16:56:58 <Norm> ...And I'll rewrite my DTD.
16:57:34 <Norm> Henry: I think brevity is really important.
16:57:57 <Norm> Norm: Ok, I'll leave it open one more week.
16:57:59 <ht> "Yahoo pipes" are the latest Web 2.0 media firestorm generators
16:58:05 <Norm> Topic: Any other business?
16:58:07 <Norm> None.
16:58:12 <Norm> Adjourned.
16:58:16 <Zakim> -richard
16:58:17 <Zakim> -Murray_Maloney
16:58:18 <Zakim> -PGrosso
16:58:20 <Zakim> -Norm
16:58:21 <Zakim> -Ht
16:58:22 <Zakim> -MoZ
16:58:23 <Zakim> -Alex_Milowski
16:58:26 <Zakim> -MSM
16:58:27 <Zakim> XML_PMWG()11:00AM has ended
16:58:29 <Zakim> Attendees were Ht, PGrosso, Norm, Murray_Maloney, Alex_Milowski, MoZ, richard, MSM
16:58:31 <alexmilowski> alexmilowski has left #xproc
17:02:43 <Norm> rrsagent, please set logs world-visible
17:02:48 <Norm> rrsagent, draft minutes
17:02:48 <RRSAgent> I have made the request to generate http://www.w3.org/2007/02/15-xproc-minutes.html Norm
17:03:15 <PGrosso> PGrosso has left #xproc
18:53:30 <Zakim> Zakim has left #xproc
19:52:26 <Norm> rrsagent, bye
19:52:27 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2007/02/15-xproc-actions.rdf :
19:52:27 <RRSAgent> ACTION: Henry: mark Sonoa system as no longer in good standing. [1]
19:52:27 <RRSAgent>   recorded in http://www.w3.org/2007/02/15-xproc-irc#T16-12-06