XProc Minutes 15 Mar 2007

See http://www.w3.org/XML/XProc/2007/03/15-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 59, 15 Mar 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Michael, Paul, Norm, Alessandro, Rui, Mohamed, Henry, Alex,
           Richard, Andrew

   Regrets
           Murray

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 22 Mar 2007
         4. Review of the 28 Feb 2007 Editor's draft
         5. Any other business?
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

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

   Accepted.

  Accept minutes from the previous meeting?

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

   Accepted.

  Next meeting: telcon 22 Mar 2007

   Regrets from Mohamed

  Review of the 28 Feb 2007 Editor's draft

   -> http://www.w3.org/XML/XProc/docs/ED-xproc-20070228/

   -> http://www.w3.org/XML/XProc/docs/langspec.html#input-output

   Alex: I'm concerned about parameters being available. We have in-scope
   parameters and importing parameters and no concept of the delta.

   Norm revisits the rationale.

   Alex suffers telecommunications issues and his discussion is postponed

   Henry: I've been working on DTDs and Schemas and so I've found lots of
   details.
   ... I'm still concerned about the question of step naming. It's irritating
   that because pipelines may have QNames for names that the pipe element has
   to have a QName rather than an NCName for its step attribute.
   ... The 99.999% case will be than an NCName will do.
   ... And there can never be more than one pipeline in scope.

   Norm wonders why it matters more to Henry than XSLT template names or
   modes.

   Henry: Because they were invented at the same time as XSLT. XSLT got to
   say that the interpretation of QNames was different for mode and template
   names.
   ... So at the very least, it seems like calling the QNames but having them
   follow the old XSLT rules not the Schema rules is a little bit unhelpful.
   ... Especially since it's a corner case of the extreme sort. I'm not going
   to lie down in the road, but it seems tacky.
   ... At the very least, more prose is needed in 5.7

   Norm: Let's explore a little bit.

   Henry: The schema union type of NCName|QName does admit to the right
   semantics and syntax.

   Some discussion of the alternatives

   Henry: What if we said that pipelines like all other steps were named with
   NCNames.
   ... And pipeline libraries had a namespace.
   ... Then you could refer to a pipeline from the outside with a QName but
   with an NCName from inside.
   ... The only substantive change is that it requires all the pipelines
   defined in a library to be in the same namespace.

   Norm: Uhm, it seems a little arbitrary, but it does solve the problem.

   Henry: It does seem every so slightly odd to define pipelines in different
   namespaces in the same library.

   Norm: Does anyone else have a feeling about this proposal?

   Proposal: We'll try Henry's proposal: Names of steps are NCNames,
   pipeline-libraries have a target namespace, all pipelines in that library
   are in that namespace. Therefore, you can refer to them by QName from
   outside and NCName from inside.

   Accepted.

   Michael: I've been struggle to keep up in the technical discussion, but
   not necessarily succeeding very well.
   ... I've exploited that fact by reading them as a sort of stranger.
   ... The biggest question I have when I read the spec is why are we doing
   this two-level specification where we have an abstraction and an XML
   syntax.
   ... To do that, you need a coherent story about how these two abstractions
   map to each other.
   ... As far as I can tell, if you try to read the document solely at the
   abstraction level, we don't say nearly enough.
   ... You don't say how our abstractions relate to each other, which ones
   are legal or not, how they're different from blocks of wood.
   ... In fact, we rely on the XML syntax for many of these things.
   ... It would be better to just treat all the extra stuff you need as
   additional information associated with XML elements.
   ... I think we thought it was a good idea at the time, but it has turned
   out not to be. Doing it well would be too expensive.

   Norm agrees wholeheartedly.

   Richard: I don't agree. The conceptual sections may not have had anything
   about the ordering of steps. But it could have done.

   Norm: Indeed, it could have been done that way, but it would be a lot of
   work. Are you in favor of improving the conceptual model.

   <MSM> [They could indeed have done. But when you look at the abstraction
   level as a thing in itself, the question becomes "why are they doing it
   this way?" And imposing an order for the purpose of calculating defaults
   seems like an unmotivated design feature.]

   Henry: It won't surprise you to know that I have a residual preference for
   keeping the conceptual model separate, but I also don't think that as
   thing stand the difference is doing enough work to justify arguing against
   the editor.
   ... Looking at XSLT 1.0 as a model, it quite cheerfully talks about
   templates and template rules independent of the elements, but it doesn't
   make a big deal about the differenc.e
   ... I think it's easier to read because it doesn't attempt to go as far as
   Michael suggests.

   <MSM> [? I think XSLT speaks about templates only in ways compatible with
   the statement "a template is an XML element"]

   Henry: I think it would be confusing to try to talk about only the
   elements.

   Michael: Two things: One, the way of talking about things that XSLT 1.0
   uses seems about right. With that, I'm in full agreement. But second,
   Henry believes they're talking about things that are different than the
   XML elements and I don't think that's the case.
   ... Perhaps I could be persuaded to believe that XSLT 1.0 postulates a
   level of abstraction distinct from the elements, but I don't think it
   does.

   <alexmilowski> BTW, I absolutely 110% disagree with Henry's proposal.

   <alexmilowski> Stupid cell phone...

   Micheal: You don't need to make a big thing of it, and I think the easiest
   way to do that is to say that it's an element, just like a "for" loop in C
   is a sequence of characters.
   ... There are lots of unanswered questions in the abstraction that are
   trivially answered by the XML syntax.

   <ht> HST would rather be silent on the relationship, but I'm happy to be
   ruled by what the editor finds congenial and/or we find out what XSLT
   actually does in this regard

   Norm: I don't hear anyone objecting to the editor attempting to merge the
   two sections.

   Richard: "A template rule is specified with the xsl:template element..."
   In fact, they have three different things: they have the template rule,
   the xsl:template, and the template itself.
   ... There's something abstract here.

   No objections. The Editor will try.

   Norm: Alex, would you like to revisit the QName/NCName step issue.

   Alex: A p:import can import a single pipeline that isn't in a library.
   ... That's a feature that we'd lose if we did this change.

   Norm: Indeed, that is the case.

   Alex: I think QNames are really simple.

   Norm recounts Henry's objection vis-a-vis interpretation of unprefixed
   names.

   Alex: Yes, but some people think that Schema got that wrong.

   MSM: Does the definition of QName specify where the namespace bindings
   come from? I don't think it does.
   ... My instincts tend to be with Henry here, but I want to understand the
   technical issue.
   ... The Namespace spec says that the way that unqualified element and
   attribute names are resolved is different. XSLT 1.0 goes further. And XSLT
   2.0 goes even further with respect to funcction names.
   ... I think we could say that interpreting step names it works this way,
   and I don't think that's incompatible with the way that QName is defined.
   ... And we could write a last call comment on the datatypes spec if we do
   find that.
   ... And if it isn't clear, we could comment on that too.

   Henry: With respect to the datatypes spec, I think it is clear that the
   in-scope namespaces in the infoset is referred to.
   ... I think it's very clear that it is an error to have an unqualified
   name of type QName in an instance document if there's no binding for the
   default namespace.
   ... We can certainly write our own rules. It's the fact that 99.999% of
   the time NCNames are all that's needed.
   ... I'm not at all clear that the case Alex mentioned should be enough to
   change our position.

   <MSM> [W.r.t writing our own rules - I think the point of disagreement
   here may be just whether doing so means we ought not to use the QName
   type, or must use a union of NCName and QName.]

   There's no way to predict if importing pipelines or pipeline-libraries
   will be more common.

   Henry: I still like the resolution above and what it amounts to when
   importing single pipelines is that you risk a name conflict.

   Norm: We did resolve this. Is there anyone that on the basis of Alex's
   observations wishes we'd resolved it differently?

   No one heard.

   Norm: Has anyone looked at the draft that includes options?

   Henry: Yes, a while ago. It looks good on the face of it, but I haven't
   looked at it line-by-line.

   Mohamed: I looked at it.
   ... I found the way that it's explained reflects the discussion, so I
   think we should keep it.

   Norm: Anyone want to reject the options draft as the status quo.

   Accepted.

   Norm: Did anyone see anything in the 28 Feb draft that they'd object to
   seeing in the next public draft.

   Mohamed: I'm concerned about the consistency of viewport-source,
   iteration-source, and xpath-source.
   ... I don't find the explanation about why some are one way and some are
   not very clear.
   ... I think sequences are just not very clear at a deep level.

   <MSM> [Checking the current Datatypes spec diff w/1.0, I don't see any
   mention of [in-scope namespaces] in the section on QName. There's a note
   that says that the mapping requires a namespace declaration to be in scope
   for the mapping to work, but that doesn't seem to determine the treatement
   of unqualified names. (It appears to contradict the normal assumption that
   if there is no default ns declaration, the QName mapping is well
   defined.)]

   Norm: I'll publish a new draft this week that I'd like to vote on for
   making public at the next telcon.

   <alexmilowski> [That seems more consistent with XSLT vs XQuery ]

   Norm: So next week, I'll see if anyone has any show-stoppers and then
   we'll look at the component list.

   No one objects to that plan.

  Any other business?

   Henry: I would like to see the various schemas appearing in the draft.

   <ht> Michael, you are right, and I was wrong -- only Schema Representation
   Constraint: QName Interpretation in Part 1 is unequivocal, and _it_ as
   written only applies to attrs of type QName (not elts), and _could_ be
   claimed to only apply to attrs in schema docs

   Ok.

Summary of Action Items

   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/03/15-agenda.html
   [3] http://www.w3.org/2007/03/15-xproc-irc
   [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [9] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[8] version 1.128 (CVS
    log[9])
    $Date: 2007/03/15 20:27:33 $

Received on Thursday, 15 March 2007 20:28:53 UTC