XML Processing Model WG

Meeting 55, 15 Feb 2007


See also: IRC log


Henry, Paul, Norm, Murray, Alex, Mohamed, Richard


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/02/15-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/02/08-minutes.html


Next meeting: telcon 22 Feb 2007

Regrets from Paul.

Face-to-face in 2007? Meeting at the plenary in November?

Still no progress. Norm notes that the Charter expires before November.

Henry: I think saying "yes" now is important even if the answer is only maybe.

Norm: I'm going to say "yes"
... We can decide if we really have critical mass, and an extended charter, a little closer and back out if necessary.

Norm: One other thing:
... Sonoa systems hasn't shown up in ages and can't be reached anymore, can we please declare them no longer in good standing?

Paul: You're supposed to contact the AC rep.

Henry: He is the AC rep.

<scribe> ACTION: Henry: mark Sonoa system as no longer in good standing. [recorded in http://www.w3.org/2007/02/15-xproc-minutes.html#action01]

Chameleon components: p:step vs. p:xslt

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0049.html

Norm attempts to describe the thread

Richard: I haven't thought much about this.
... 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.

<Zakim> MSM, you wanted to ask how validation is trickier with just one GI; validation seems easier to me with distinct GIs

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.

<MSM> pipeline ::= (step | #any)*

<MSM> allows anything that matches the wildcard to be ignored.

<ht> Subst group is the XML Schema technology

Norm attempts to describe what he recalls at Murray's place. Mostly, I think we just didn't think about it hard enough.

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.

Norm: Yeah, but presumably that's a quality of implementation issue.

<MSM> <xsd:schema><xsd:element name="mycomponent" susbtitutionGroup="p:step"/></xsd:schema>

Alex: Yes, but we're putting that one small barrier there.

<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.]

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.
... 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.

<MSM> Henry, what role do you expect the notion of 'validity' to play?

Henry: 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.
... 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.
... If you have to use Widgets, Inc.'s schema in order to use their extensions, then that's a good consistency check.
... That tends to make me think that it's a good idea.

Alex: I'm really in favor of this, but I still want to poke holes in it.
... We've said that we want our language to be open, so you can add documention, etc.
... 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.

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.

Alex: That means that we have to come up with some other mechanism to embed documentation.

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.

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.

<Zakim> MSM, you wanted to ask what a pipeline processor should normally do with <p:pipeline><p:step .../><my:element .../></p:pipeline>

<alexmilowski> (yes... e.g. no one validates an XSLT transformation document)

Michael: Our current design is that given a pipeline as above, my:element will be ignored.

Norm: Yes.

Michael: In that case, I don't think Henry quite answered Alex's question.
... 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.

Henry: You're right.
... If you've failed to do so then nothing will happen.

Michael: That depends purely on whether or not the pipeline processor uses the substitution group information.
... It's possible to write a processor such that it validates and then uses the PSVI information.

Richard: That's an interoperability nightmare.

Henry: We haven't tackled the question of how you make the syntax/semantics link for new steps.

Murray: This conversation is coming at weird angles for me.
... We have a mechanism for declaring steps, right?
... I would have thought that's were we'd be talking about this.

<richard> i agree with murray: we tell the pipeline about steps by declaring them, not by a schema

Murray: 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.
... And you could not bother with the validation if you just didn't care.
... The implementation is going to get it's information about the step from that declaration.

<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.

<Zakim> ht, you wanted to disagree with richard

Henry: I think you're right, but going a little further I'm still worried about the interoperability story in the non-chameleon case.
... Consider Michael's pipeline: <p:xslt>...</p:xslt><my:step>...</my:step>
... Now consider two impls: one produced by the owner of the my: namespace with the step declaration built in.
... Now consider Norm's impl. It doesn't have any builtin step definition for my:step so it ignores the my:step.

<richard> is it allowed for implementations to have extra built-in step types? shouldn't you have to import a library to access them?

<MSM> Henry, what does the second implementation do with the declaration of my:step ?

<richard> bingo!

Henry: I think that means you must declare every step that you use other than the ones in the spec.
... 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.

<Zakim> MoZ, you wanted to give his two levels of disagreement on p:xslt

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.

<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.]

Mohamed: 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.
... With the p:step the declaration of the name was an indication.
... 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.

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.

<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_ declare-step-type for it in the pipeline or in a library it includes"

Mohamed: That's why I'm opposed to p:xslt and prefer p:step.

Alex: In the email thread, I said that we should identify extension namespaces (like XSLT)

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0055.html

Alex: I'm not sure I want to require such an attribute, but it is a nice double check.

<MSM> [Alex, remember though that that feature in XSLT doesn't map to any existing schema language -- it requires some rather ad hoc checks.]

Norm and Alex discuss the declaration vs. namespace aspect.

<Zakim> MSM, you wanted to propose a strawman (? or real?) argument going the other way.

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.
... 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.
... 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.

<Zakim> ht, you wanted to a) check what Richard/MoZ were saying and b) comment on AM's point

Henry: I'm not sure I understood what Mohamed and Richard were saying.
... We don't have to require validation with a normative schema in order to use one to define the semantics and constraints.

ht, you got dropped!

Richard: In the current system, if you misspell a step name then you get an error.

<alexmilowski> yes

Richard: In the other system, if you misspell a step name, isn't it just ignored?
... If that's true then this seems to be really bad for error detection.

<alexmilowski> ...that is why I wanted that "extension namespace" declaration...

Henry: I think that's a real issue.

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.

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.
... If we do that then I think we can still say that every user defined step must have the following abstract content model.
... I don't think there's a vulnerability there to people smuggling in all sorts of nonsense.
... 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.

<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.]

Henry: 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.
... Another possibility which I think I might prefer is to say that you have to declare your ignore-me namespaces.

Norm: Yes, I like that a little better.

Alex: Henry's last comment is exactly what I was going to say.

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.

<MSM> question: how is the type attribute declared / to be declared?

<MSM> or does that matter? does the status quo specify?

Results: four in favor of the change, three for the status quo, one abstention. That's not consensus for a change.

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.

Paul: I didn't feel strongly.

Richard: I didn't feel strongly either.

Henry: Come back to this a week later?

Alex: Maybe see some pipelines?

<MSM> give someone an action to summarize the question, the options, and the arguments each way

Richard: I think we've exposed a lot of the issues talking about it today.
... There isn't really very much to choose between them.

Henry: I think we should take Alex's offer up.
... I'll try to recast some examples too.
... And I'll rewrite my DTD.
... I think brevity is really important.

Norm: Ok, I'll leave it open one more week.

Any other business?



Summary of Action Items

[NEW] ACTION: Henry: mark Sonoa system as no longer in good standing. [recorded in http://www.w3.org/2007/02/15-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/02/22 17:07:14 $