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

XProc Minutes 29 Nov 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 12 Dec 2007 14:01:39 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ir3368ks.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/11/29-minutes

Sorry for the delay...


                                   - DRAFT -

                            XML Processing Model WG

Meeting 93, 29 Nov 2007


   See also: IRC log[3]


           Norm, Paul, Henry, Rui, Richard, Mohamed, Andrew

           Alex, Murray




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 6 December 2007?
         4. Comment #68 Comments from the XSL WG
         5. Comment #69 should default ports be named
         6. Comment #70 circular imports
         7. Comment #71 http-request/etc. and URI encoded references
         8. Comment #72 name attributes and fragment identifiers
         9. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/11/29-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/11/15-minutes


  Next meeting: telcon 6 December 2007?

   Norm, let's meet next on 13 December isntead

   Mohamed gives likely regrets for 13 December

  Comment #68 Comments from the XSL WG

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C068

   1. Resolved

   2. Why all these steps?

   Norm: I don't really have any sympathy for their position

   Some answers: pipelines are easier to understand, streaming is likely to
   be easier in some cases, ...

   Henry: I think it's worth emphasizing that we anticipate that a
   significant user community will be processing very large inputs through
   very simple pipeliens and having to pay the cost of an XSLT runtime for
   this is not very attractive

   Norm: What do we say about the fact that we don't guarantee streamabilty

   Henry: No, that's a QoI issue.

   Norm: Ok, let's start there. Anyone want to add anything else?

   Richard: The question about streaming is more specific.

   Henry: It's very easy to detect a very small subset that's streamable, but
   that subset covers a lot of use cases.

   Richard: If you want to do some analysis, you can stream up to a point and
   then build a tree which is less practical for XSLT

   3. Parallel executions

   Norm: I don't understand the comment.

   Henry: I don't understand the third sentence.
   ... The classic case is a document styled with a stylesheet generated from
   the same document. What's the problem?

   Richard: I think maybe they just don't understand that we're saying you
   have to make it work.

   Norm: I think we should ask them to clarify.

   Richard: The statement in the spec about "the order determined by the
   connections" might be being taken too strong.

   Henry: Something like, "in an order consistent with the connections"...

   4. resolved

   5. resolved.

   6. resolved

   <scribe> ACTION: Norm to reply [recorded in

  Comment #69 should default ports be named

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C069

   Agreed: we'll give them unreferencable names

  Comment #70 circular imports

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C070

   Mohamed: I don't find any context where it would be confusing

   Norm: It's not possible on pipelines anymore, it's only on other compound

   Richard: It's only the defaulted output ports of subpipelines. The only
   reason for allowing them is to save people from making up names in simple,
   linear pipelines.
   ... I think if they want to make reference to names out-of-order then they
   should have to declare the port.

   Mohamed: I'm ok with that. It'll be defaulted on both ends usually.

   Henry: I think his message has been overtaken.
   ... Our discussion at the plenary clarified the issues a lot and moved us
   ... It would be good to get Alex's input. But we could talk about the last
   three paragraphs.

   Richard: The main point of Henry's message is that there's a proof that it
   can be made to work.
   ... Henry's description is based on the approach that I'm taking which
   does several passes.

   Norm: I suggest we leave this open for a week to get Alex's input.

   Henry: We need to say something about reentrancy as well as circularity

   Richard: I don't think the term reentrant is generally understood to mean
   what you mean here
   ... It's the diamond pattern: a imports b and c and b and c both import d

   Norm: Yeah, the editor will have to figure out how to express that. Poor

  Comment #71 http-request/etc. and URI encoded references

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C071

   Norm: I think they're all LEIRIs and that's all we need to say

   Henry: I think we should say that.

   Norm: I agree. I'll see if that satisfies Alex.

  Comment #72 name attributes and fragment identifiers

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C072

   Norm: There was some pushback on the places where I put names, so I think
   we probably need to discuss fragids and MIME types again

   Ricahrd: I think there's value in having the names independent of the
   fragid question, it improves error reporting.

   <ht> Here's the only place I can find which discusses fragids:

   Henry: If we do this, then we have to address the question of uniqueness.
   Do we make these things unique like their sisters and cousins or not?
   ... We have a general purpose mechanism for naming bits of XML syntax,
   it's xml:id.
   ... I'd like to set this aside from the question of our own XPointer
   scheme for a moment.
   ... It feels a little bit like we have a hammer in our hands so everything
   looks like a nail.
   ... The most bizarre aspect of this is the fact that there's no discussion
   of the name attribute in some of those places, like p:declare-step.
   ... If you give a pipeline library a name attribute, people are going to
   think you can refer to it by name.
   ... We don't really expect that to mean anything.
   ... Users are going to think there's some deep complexity there but there
   isn't, there's barely any there there.

   Richard: You took the names out, Norm, but they still get names like !3

   Norm: Yes, but if we undo the fragid decision...

   Richard: Like I said, I use the names to report errors and I use the !
   names if they don't have any.

   Henry: So what's the question?

   Richard: Well, there's no doubt that all steps have to have names because
   they have ports.
   ... So it's the things that don't have ports: pipeline-library, catch,
   when, otherwise, ...

   Henry: My compromise position is, I'm a little nervous, but I could live
   with putting names on the schizophrenic contstructs.

   Richard: It's the things inside try and inside choose except group.

   Henry: Like I said, I could live with names there; it doesn't really
   conflict with the object model.
   ... It's declare-step that I think shouldn't have one.

   Richard: That's funny, I was going to go the other way. It seems that
   declare-step should be like pipeline in this regard.

   Norm: We do have this weirdness with namespace and name in pipeline

   Henry: I agree, pipeline and declare-step should have the same naming

   Norm: Name doesn't work then because they're NCNames.

   Richard: Why would you ever want to have a single pipeline library taht
   declare steps in separate namespaces?

   Norm: Because you aggregated them after you wrote them over time; I don't
   see how the library should have a bearing on the names.

   Richard: Do we allow any steps to be in no namespace.

   Norm: Yes, though it's not clear that we meant it to be that way.

   <MoZ> no namespace is impossible because of ignorable-prefix

   Norm: So where are we?

   Henry: I'm prepared to float the following pair of changes:

   <MoZ> <foo:step xmlns:foo="">...</foo:step>

   Henry: Reinstate optional names on when/otherwise/catch and remove name
   from pipeline and namespace from pipeline-library

   Norm: You can't remove name from pipeline, that's how the steps refer to
   its ports

   Henry: No, they use the local-name of the type attribute

   Norm: Uhm. My initial reaction is "eew" but maybe I need to think about it
   some more.

   Henry: Having to write name="foo" type="my:foo" is just hopelessly

   Richard: The reason that pipeline is like this is because if its usual
   ... You're allowed to have an unnamed pipeline at the moment.
   ... And an untyped one.

   Scribe lost Richard's thread

   Henry: We'll never see names and types that are different

   Norm: I don't agree, I might name all my pipelines 'main' irrespective of
   their type

   Henry: So what I said before with a small modification:

   1. Remove name from declare-step and pipeline-library

   2. Add name to when/otherwise/catch

   3. Remove namespace from pipeline-library

   4. Remvoe the magic about name/namespace for defaulted types in a pipeline

   5. Make type required on a pipeline in a pipeline library

   Norm: So the editor should give that a wack?


  Any other business?



Summary of Action Items

   [NEW] ACTION: Norm to reply [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/11/29-agenda
   [3] http://www.w3.org/2007/11/29-xproc-irc
   [7] http://www.w3.org/2007/11/29-xproc-minutes.html#action01
   [12] http://www.w3.org/XML/XProc/2007/08/09-minutes.html#item05
   [13] http://www.w3.org/2007/11/29-xproc-minutes.html#action01
   [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [15] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[14] version 1.128 (CVS
    $Date: 2007/12/12 19:00:35 $

Received on Wednesday, 12 December 2007 19:01:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:45 UTC