Minutes for XProc WG telcon of 26 Jan 2006

See http://www.w3.org/XML/XProc/2006/01/26-minutes.html

                                   - DRAFT -

                            XML Processing Model WG

26 Jan 2005

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Rui, Norm, Alex, Henry, Paul, Murray, Erik

   Regrets
           Richard, Andrew, Jeni

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Administrivia
         2. Accept this agenda?
         3. Accept minutes from the previous teleconference?
         4. Next meeting: 2 Feb 2006.
         5. Tech Plenary
         6. Welcome Murray Malone
         7. Technical: Requirements document
         8. Any other business?

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

  Administrivia

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/01/26-agenda.html[4]

   Accepted

  Accept minutes from the previous teleconference?

   -> http://www.w3.org/XML/XProc/2006/01/19-minutes.html[5]

   Accepted.

  Next meeting: 2 Feb 2006.

   Any regrets?

   Norm is on vacation 2 Feb and 9 Feb

   Paul to chair 2 Feb and 9 Feb

  Tech Plenary

   Registration is now open; discounted rates at the Sofitel end 6 Feb 2006.

  Welcome Murray Malone

   Murray joins us as an invited expert. Welcome, Murray!

  Technical: Requirements document

   Norm suggests that his review is mostly editorial.

   Murray: Reading from a "new user" perspective I found myself getting lost
   because the definition of terms followed the design principles
   ... Hopefully we'll have a drawing of the model eventually. That also
   should probably precede the design principles.
   ... I'd like to change the order of the design principles; from high-level
   to lower-level. So there's a progression.
   ... I felt the same way about the list of requirements; starting with
   "this is an XML language" and moving through to more technical issues.
   ... I sent out a bunch of editorial comments today, most are details. A
   few places where I don't understand.

   <Zakim> ht, you wanted to ask about "component vocabulary"

   Henry: I propose that we delete "component vocabulary" unless and until we
   need it for something.

   Norm: that works for me.
   ... I proposed to use it in the definition of "Pipeline Document" but I'm
   happy to not use it.

   Alex: In my mind it has a very specific purpose but if we aren't using it
   I guess it makes sense to remove it.
   ... I'll remove it.
   ... From my perspective, I think the purpose of that was to encapsulate
   the idea that in addition to things that have known vocabularies, there
   are pipeline steps that need to have their own things that they operate
   on.

   Henry: All I'm suggesting is that we wait until we have a particular
   instance in front of us to talk about.

   Alex: With respect to Norm's comment that we need "pipeline document",
   that's what I thought "specification language" meant.

   Murray: "Pipeline document" sounds like something going through the
   pipeline. A "pipeline specification document" would work.

   <ebruchez> I agree.

   Norm: I thought "specification language" was the description of the
   elements and attributes that one uses to *write* a pipeline specification
   document.

   Consensus to use "Pipeline Specification Document" instead of
   "Specification Language"

   Murray: What is the name for the thing being operated on?
   ... Let's say we're talking about a DocBook manual for Awk. How do we
   refere to that document as it's going through the pipeline.

   Henry: I don't know yet. Part of the problem is we're still discussing the
   right way to conceptualize what's going through the pipeline.

   Murray: "Pipeline fodder"?

   Alex: I see where you're going. Maybe we should come up with a term for
   it.

   Erik: I just wanted to say that "the active thing" seems to imply that
   there's only one.
   ... I'm not sure what active means in this case.

   <ht> Erik and Norm have covered my point

   Norm: I don't think of a pipeline as having something flowing through it.
   Not a single thing, anway.

   Murray: Then why call it a pipeline?

   Erik: I agree with Norm. I still think we can call it a pipeline because
   we have stages that are linked together, but it's not like "liquid"
   flowing through the pipeline.

   Murray: It's more like a sausage making machine.
   ... Perhaps we're talking about source and target documents?

   Erik: There may be many.

   <ht> Every steps has inputs and outputs

   <ht> they may be connected in complex way

   Murray: For every step in the process there are zero or more inputs and
   outputs. For now, can we just call them source and target doucments.

   Henry: No, I like inputs and outputs.
   ... I think that's the right terminology.

   Norm: We already use inputs and outputs in a lot of places. Let's stick
   with that until (or if) we find we need something else.

   Alex: I'll add Input Document and Output Document to the vocabulary
   section.

   Discussion of infoset vs. object model vs. PSVI discussion resumes.

   Henry: Murray's point is well taken, we should say something that
   describes what we mean by infoset.

   <ht> "infoset" is the name we give to any implementation of a data model
   for XML which supports the [Infoset] vocabulary

   Murray: Many of the "technology neutral" requirements would be easier to
   understand if we made this clear up front.
   ... The design principle "technology neutral" seems to be two parts: the
   technology wrt infosets and object models and there seems to be platform
   neutrality.

   Norm points out we also have 4.11

   Murray: then it looks like we have three flavors

   General discussion of how to factor the design principles/requirements

   Murray: 4.14 is a design principle. A requirement falls out of that. What
   I'm saying is that there are really high-level principles, platform
   neutrality, language neutrality, vendor neutrality, etc. Requirements fall
   out of some of these.
   ... A lot of the requirements that are longer than one sentence include a
   design principle that needs to be pulled to the top.
   ... Consider 4.10. There's a design principle there, this language should
   be able to work with all existing XML technologies and be prepared to deal
   with new ones

   Norm concurs if for no other reason than because it will make the
   technical requirements crisper

   Alex: Consider 4.1

   Murray: Software allows you to specify inputs and outputs.
   ... Something about familiar software paradigms. 4.3 and 4.4 seem to fit
   in there too

   Alex: Maybe this rolls back to a design requirment like "we have control
   over the flow of documents and their processing"

   Murray: Hopefully we're not going to invent a new language form to express
   a while loop. We're going to use while. If that's what we need, we're
   going to use common paradigms.

   Alex: 4.11 is a big one. I collapsed two things together.

   They seemed similar.

   Norm: 4.11, 4.14, [Murray: and 4.17] all collapse together as design
   principles

   Alex; but we want to keep the requirement that it isn't API-based

   Alex: In 4.17 there are issues that involve serialization that we need to
   be aware of

   Murray: Can't we refer to something for this?

   Alex: Yes. (XSLT 2.0 Serialization, the scribe assumes)

   Murray: How about a design principle that says something like "not
   withstanding serialization deltas" and go on to explain that with a
   document reference.

   Alex: I was going to put in the requirement that we're going to do what's
   already been done and point to the document
   ... Design principle: we don't need to reinvent things done by other
   groups

   Some discussion of 4.18 and whether or not it's part of 4.10

   Alex: I'm going to try to roll them together

   Murray: we need common naming.

   Norm points out that there are two separate issues here but doesn't object
   to combining them in the spec

   Alex: that gets us to 4.19.

   Murray: I think iteration needs to be in the group with specifying inputs
   and outputs, conditionals, etc.
   ... There just needs to be a progression in the requirements.

   Murray: The term "allow" isn't very helpful and something more specific is
   needed.

   Norm: "allow" didn't bother me.

   Murray: I did that in each instance
   ... Allow can just mean "give permission" and that's not sufficient.

  Any other business?

   None.

   ADJOURNED

   [End of minutes]

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

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/01/26-agenda.html
   [3] http://www.w3.org/2006/01/26-xproc-irc
   [4] http://www.w3.org/XML/XProc/2006/01/26-agenda.html
   [5] http://www.w3.org/XML/XProc/2006/01/19-minutes.html
   [6] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [7] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[6] version 1.127 (CVS
    log[7])
    $Date: 2006/01/26 17:28:48 $

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.