See also: IRC log
Norm is on vacation 2 Feb and 9 Feb
Paul to chair 2 Feb and 9 Feb
Registration is now open; discounted rates at the Sofitel end 6 Feb 2006.
Murray joins us as an invited expert. Welcome, Murray!
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
... 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
... 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,
... 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
... Allow can just mean "give permission" and that's not sufficient.