- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 19 Jan 2006 12:10:55 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87slrk87og.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/01/19-minutes.html
- DRAFT -
XML Processing Model WG
19 Jan 2005
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Rui, Alessandro, Henry, Paul, Andrew, Richard, Alex, Erik
Regrets
Jeni
Chair
Norm
Scribe
Norman Walsh
Contents
* Topics
1. Administrivia
2. accept this agenda?
3. accept minutes from the previous teleconference?
4. next meeting: 26 Jan 2006.
5. Tech Plenary
6. Requirements and Use Cases
7. Any other business
* Summary of Action Items
----------------------------------------------------------------------
**
**
<scribe> Scribe: Norman Walsh
<scribe> ScribeNick: Norm
Date: 19 Jan 2005
Administrivia
accept this agenda?
-> http://www.w3.org/XML/XProc/2006/01/19-agenda.html[4]
Accepted.
accept minutes from the previous teleconference?
-> http://www.w3.org/XML/XProc/2006/01/12-minutes.html[5]
Accepted.
next meeting: 26 Jan 2006.
Any regrets?
Possible regrets from Norm
Henry to chair in Norm's absence
Tech Plenary
Registration is now open; discounted rates at the Sofitel end tomorrow
Requirements and Use Cases
Thank you, Alex
Alex: Some consolidation needed on the use cases; they aren't tightly
coupled with the requirements yet
... Many use cases contain the same components.
... It might be a good idea to factor out the common bits
Norm: Was lack of discussion about PSVI in "Infoset Processing"
intentional?
Alex: It does say augment...
Norm suggests "Infoset, augmented infoset, or other data models"
Erik: Is there agreement already that the infoset is our minimum?
Alex: From an XML perspective, that seems right
Norm: Erik, did you have something else in mind?
Erik: No, that's fine
Alex: Augmenting or annotation infosets is something I've always imagined
a pipeline language could support
Norm points out some ways that XDM is different from Infoset.
Erik: can you consider the XDM as a superset of the Infoset?
Richard: It's not a subset or superset but it has a correspondence
Some discussion of XDM follows.
Richard: I'm worried that we're trying to include too many things. We
should concentrate first and formost on infosets and anything else should
be an extension
Erik: I'm inclined to agree, but we have also had mail that suggests we
need to support some things that aren't infosets (documents containing
only text nodes, etc.)
... The best place to look if we need to do those things may be XDM.
... Rather than specifying our own thing, we should point to XDM.
... This might also make it easier to deal with parameters as they could
be the XDM instances from some previous process
Alex: I can see the advantage of XDM, but there are lots of simple
pipelines that don't require that
Richard: I assume at this stage we aren't planning to standardize the
representation of XDM. One way to do this is to say that you pass infosets
or extended infosets and anything you want to pass like XDMs, you
represent them as extended infosets
Norm: that appeals to me
<alexmilowski> How about: "At minimum, an XML document is represented and
manipulated as an information set. Use of a super-set, augmented or
extended information sets, or data models that map to information set
should be allow be implementations."
Erik: this is a minimal goal; we may come back to this later
Richard: I think that saying things like XDM are represented as extended
infosets at least gives us a handle on what kinds of things can be in
components
... I'd like to say that what passes between components are infosets,
possibly augmented
Erik: I think one thing we are trying to say is that this is a minimum
requirement. The model must support passing infosets between components.
If an implementation wants to say that it supports passing things from
XDM, maybe we should try to allow this.
Richard: I did not intend to allow you to pass a sequence of integers
between components
... I want extensions such as that to be outside the scope of what we are
standardizing.
Erik: XDM is an XML Data Model and it does allow more things
<Zakim> MSM, you wanted to express uneasiness about the phrase
"represented as" followed by the phrase "an infoset". Infosets are way too
abstract to serve as representations in any
MSM: Richard made me very nervous by speaking about data models
"represented as" infosets. It suggests that infosets are APIs or data
structures and I think they are neither. They are more abstract.
Richard: I understand your reservation and I agree essentially.
... I certainly wasn't implying anything about an API; I simply wanted to
constrain things sufficiently such that we could speak of passing
information items around rather than talking about integers and sequences.
MSM: I think that can be paraphrased as "data models conceptualized as
infosets" and I'm happy with that.
<richard> i am happy with "conceptualized as" rather than "represented as"
Norm: Any other concerns about design principles?
Moving on to terminology...
Alex: I tried to factor out the the distinction between straight-through
processing as pipelines and process models which may be more complex.
... Those are both really the subject of our spec.
Henry: I don't find this helpful. It's useful to get started on iterating
over this.
... I don't think restricting pipeline to "straight through" is very clear
or likely to work for this group.
... I agree the distinction is important, but I'd rather not do it this
way.
Richard: I partly agree with Henry because I think "process model" is
probably interpreted as a more general term and includes descriptions of
how they are processed that doesn't include things that we're going to
describe.
Norm: I concur
Alex: Maybe we could define one and then I could take a pass through to
use that term consistently.
Norm: I think of the pipeline as the whole thing
<ht> HST likes 'XML Pipeline' for the whole space, 'pipeline language' for
AM's 'specification language' and 'pipeline document' for an XML document
in a pipeline language
Richard: I see pipeline conceptually as the flow of a document through a
series of components. They aren't linear.
Erik: If we do use the term "pipeline", I'd like that to mean the whole
thing.
<ht> +1 -- A pipeline is a configuration of steps, steps involve
components and connectivity and parameters
Henry: I like "pipeline" for the whole thing that documents pass through,
I like "pipeline document" to describe a document in a "pipeline
language". Pipelines have "steps" which consist of "a component" plus it's
parameters and connectivity.
Alex: I don't like the term "process model". So I'm happy to consolidate
these things into "pipeline"
Richard: A step can be used in isolation, but when you specify what a unix
program does, you specify what it's standard input/output/error and
parameters are and that seems to be consistent with "component"
Erik: A component could be XSLT or XQuery, but a step is an instance of
one of those things.
Richard: I agree that a step is an instance of a component with various
things associated with it.
Erik: "Step" has a strongly linear connotation, but we might have things
in parallel or conditional.
Richard: Yes, but it is used in descriptions of programming languages and
that covers the parallel case for me.
Alex: Maybe we can take a stab at defining "pipeline" and "step" to
replace process model.
Alex proposed something the scribe failed to capture
<alexmilowski> A pipeline is a configuration of steps that defines, but
not limited to, order, dependencies, or iteration along with their
configuration.
Norm asks about the term "component vocabulary"
Some discussion follows
<ebruchez> We've used the term "interface" to describe how a component
communicates with the rest of the pipeline
Alex: when I say vocabulary, I actually mean an XML language (a set of XML
elements)
Richard: I think what Erik described as an interface is what I described
as a "component specification": the thing that a generic pipeline editor
would need to have
... to allow you to join components together
Alex: maybe we could consolidate "use environment" and "binding"?
... there's a whole context in which a pipeline runs.
Richard: I think "environment" is quite widely used. Binding seems more
specific.
Alex: Maybe we could use "pipeline environment"
Norm: Yes.
Alex: I suggest that people send feedback by email. The two most critical
bits are: which things should be combined or refactored and the
connections between requirements and use cases.
<richard> The great thing about the term "pipeline" is the associated
plumbing metaphor - sources, sinks, the ability to insert Ts and so on
Alex: I'll shoot for another draft on Tuesday.
Any other business
If you're going to be at the f2f, please describe your conflicts for
Monday/Tuesday by email.
If you're not going to the f2f, please indicate if you'd like to dail in
for all or part of our meetings. Taking into account the time of day in
your part of the world :-)
ADJOURNED
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.
Received on Thursday, 19 January 2006 17:11:16 UTC