- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 15 Feb 2007 12:20:19 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87odnvjq24.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/02/15-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 55, 15 Feb 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Henry, Paul, Norm, Murray, Alex, Mohamed, Richard
Regrets
Alessandro
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 22 Feb 2007
4. Face-to-face in 2007? Meeting at the plenary in November?
5. Chameleon components: p:step vs. p:xslt
6. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/02/15-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/02/08-minutes.html
Accepted.
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[6]]
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?
None.
Adjourned.
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[9]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/02/15-agenda.html
[3] http://www.w3.org/2007/02/15-xproc-irc
[6] http://www.w3.org/2007/02/15-xproc-minutes.html#action01
[9] http://www.w3.org/2007/02/15-xproc-minutes.html#action01
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[10] version 1.127 (CVS
log[11])
$Date: 2007/02/15 17:18:58 $
Received on Thursday, 15 February 2007 17:20:55 UTC