W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

XProc Minutes 15 Feb 2007

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:49 GMT