XML Processing Model WG -- 26 Jan 2005

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Date: 26 Jan 2005

Yes. This week.

I'm on vacation 2 Feb *and* 9 Feb, however

Bad timing really, but I need to lie on the beach for 10 days so there :-)

<MSM> something is going to give, not clear what.

<MSM> i may be late, apologies if so

Administrivia

accept this agenda?

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

Accepted

accept minutes from the previous teleconference?

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

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

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.

Any other business

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.

ADJOURNED

- DRAFT -

XML Processing Model WG

26 Jan 2005

Attendees

Contents