XML Processing Model WG

27 Feb 2006 A.M.


See also: IRC log


Norm, Alex, Rui, Michael, Erik, Henry, Murray, Richard



Scribes: Norm, Mon am; Alex, Mon pm; Henry, Tue am; Michael, Tue pm

Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/02/23-minutes.html

<MSM> good morning, all

<scribe> Postponed until tomorrow AM

Next meeting: 9 Mar telcon (not including tomorrow, of course)

Any regrets?

None given

Another f2f?

The next Tech Plenary is 18 months away; maybe we should meet in December in Boston colocated with the XML 2006 conference?

Murray suggests that December isn't a good time

Murray suggests that perhaps August, colocated with Extreme 2006 might work better?

Technical discussion; Requirements and use cases

Norm suggests that we might look at some use cases

Alex observes that many of the use cases overlap

Michael says that's ok

Murray thinks we could get this down to three use cases

There's no clear consensus that that's a good idea

Murray suggests that most of the uses can be described from a single example

The group struggles with technology issues; USB media, wireless connections, CVS repositories, you name it.

Use case 5.1: Extract MathML

The output is images, rendered either with a MathML image renderer or an SVG renderer.

Henry: Is this really a pipeline use case?

Micheael: Yes

Agreement settles on the interpretation that SVG images must be used by the MathML rendere to build an image of the equation

Some concern that this use case is at the edge of what we consider our charter

Move this use case near the end.

Use case: 5.2: Style an XML Document in a Browser

Norm: This doesn't seem like a pipeline use case; the browser UI ought to let you pick a stylesheet

Richard: This may have been mine; I don't think it was user choice.
... I have several stylesheets that render very different documents. Right now I need different documents with different PIs
... The idea was that some parameter in the URI might choose the stylesheet

Henry: That's the old Adam Bosworth use case, I want to pack up the pipeline in the URI

Some discussion of parameters and servers and clients

Richard: Being able to invoke a pipeline on the client with a parameter

Micheal: Split this into two or possibly three: 1. allow a pipeline to take a parameter and choose processing on that basis; 2. On the server; 3. On the client (in a browser)

Richard: There's an intermediate case: the pipeline and parameters are specified by a URI

Alex: I think it's a non-use-case

Murray: The use case is, I'm going to click on a link and get back the right document

Erik: This use case is different because of the URI

Richard: We might decide not to do it, but I don't think the URI part is out of scope (Norm had suggsted it was)

Micheal: I think it's relevant because a desire to implement the pipeline in the browser may have an impact on the language design

Richard: This looks more like a fragment identifier syntax issue because parameters are usually resolved on the server

Erik: Do we have anything else that has this has this pattern

So this boils down to a fragid syntax that evaluates a pipeline with parameters

The semantics is that anyway

Micheal: That's got too much solution not enough problem statement in it

Richard: The problem is having a URI that refers to a pipeline with parameters in such a way that the pipeline can be evaluated on the client with those parameters

Micheal: This still seems more like a solution, but leaving out the URI would probably be leaving out what some feel is the critical part of the use case

<Zakim> MSM, you wanted to propose a clarification / alternative to 'understand the use cases'

Michael: We don't need to reconstruct what the original submitter meant

Norm: Absolutely

Use case 5.3: Apply a sequence of operations

"Apply a sequence of operations such XInclude, validation, and transformation to a document"

Henry: I wonder if we should make this more concrete: xinclude, remove xml:base attributes (leaving the base-uri property!), validate with a schema, absolutize all "anyURI"s
... not all the steps are W3C-spec specified, and it requires some persistents of infoset properties. You can't implement this by serializing between each step.

<scribe> ACTION: Henry to write this example for the use cases document [recorded in 27-morning-minutes.log]

Richard: There are two infoset things that are interesting in the example, the base-uri property and the type anyURI being assigned to things
... Proper serialization would put the xml:base attributes back in

Separate out the case where we abandon a pipeline that fails to satisfy a condition

Michael: Abort if a step fails

Richard: Steps have to be able to report if they failed

Use case 5.4: Run a custom program

General agreement that "display the result in a browser" is a red herring here

Use case 5.4: Run a custom program

General agreement that "display the result in a browser" is a red herring here

Use case 5.5: Service Request/Response

Michael: The underlying substantive requirement is that the pipeline must be less complex than doing the work

Alex: it's the mirror image of 5.2

The use case here is that the pipeline language makes it easy to send the pipeline somewhere else and get the result back

Richard: it shouldn't be the case that you specify the steps by some name that's only interpretable on one machine

Murray: This is platform, language, and environment neutrality

Richard: This implies that you are sending the data (e.g. in a POST request) because the data may not be available by URI

Murray: It may put a constraint on the language to allow the pipeline to build infosets on the side and not require them to be written to disk

Richard: You can also use multi-part MIME, for example

Use case 5.6: XQuery and XSLT 2.0 Collections

Alex: I think this was supposed to capture the idea of processing a collection of documents with XSLT 2.0

Michael: I would like my pipeline processor to come wiht an XQuery component built in. If it produces a collection of documents, I don't want the pipeline to reject it.

Process the output of an XSLT 2.0 step that is more than one document. Have a pipeline step that starts with a collection of documents.

Use case 5.7: A Simple Transformation Service

<ht> http://www.rfc-editor.org/rfc/rfc2392.txt, for the 'cid' URI scheme, which can be used to address multipart-mime parts

Henry: Components map from infosets to infosets. Pipelines may have non-XML inputs and produe non-XML outputs.

[Scribe fails to capture all of the discussion]

<MSM> several possible decisions: (1) pipeline implementations are allowed to provide input and output wormholes

Norm: The use case is that I have a pipeline, the first step of which constructs XML by magic, and the last step of which consumes XML and does magic with it.

<MSM> (2) implementations are required / expected to provide wormholes, but the choice of which ones to provide is implementation defined

<MSM> (3) specific wormholes are required to be supported

Alex proposes a use case that the pipeline be able to extract information from an HTTP request

Alex, for example, should the authenticated user be available as a parameter

Richard proposes that this could be accomplished with a pipeline component that can provide that

Alex: In my implementation, all of the HTTP content headers are available as standard parameters

Erik: What seems to be important is that it seems to be out-of-scope to deal with the request in the core language

Alex: There's a flip side, I'm a user developing a pipeline and I'm putting it in a servlet environment.

Murray: And why not put it in a component?

Alex: Because there's a non-uniformity about HTTP

<Zakim> MSM, you wanted to ask for clarification and to ask for clarification

Michael: it seems that there are three things we could say about wormholes.
... 1. They may exist; 2. Implementations are expected to provide them; 3. Specific wormholes are required.

<MSM> then question for AM: which are you arguing for?

Murray: It seems to me that somewhere in the middle of a pipeline I might want to be able to interact by HTTP

That's different because in Alex's case, the pipeline is fired by the request

Richard propose pipeline environment variables

Erik: Any of these things that we introduce into the language will make it more complicated

Alex proposes the use case that a pipeline be activated by an HTTP request, do some processing, and produces at output an HTTP heards

Richard: And he wants the pipeline ot have an environment that lallows information about that http request to be available at any point in the pipeline

Use case 5.8: An AJAX Server

Agreement that it's ok

Use case 5.9: Dynamic XQuery

Agreement that it's ok

Use case 5.10: Read/Write Non-XML File

Agreement that it's ok

Use case 5.11: Single-file Command-line Document Processing

Agreement that it's ok

Henry: Suggest that it be near the top

Use case 5.12: XInclude processing

Norm: Collapse steps 2 and 3

Michael: Spawn two near twins:
... Add a a validation step (validate before, after, and both before and after)

Perhaps 5.3 and 5.12 need to be combined

Use case 5.13: Document Aggregation

Michael: There's a question here of the level of dynamism.

Documents listed in URIs? A collection of documents available directly?

Use case 5.14: Update/Insert Document in Database

The important part of this use case is that it introduces conditionals

The conditionality is at the level of the pipeline, not inside a component

Use case 5.15: Content-Dependent Transformations

This is a switch or choose statement.

The XPath condition is built into the language.

Henry: In the background here is the tradeoff between conditionals in the

language and on the ohter hand having just try/catch and failure

Use case 5.16: Configuration-Dependent Transformations

Murray: Let's say "Device example" instead of "Mobile example". Add a step

4 that translates to Braille for example

Murray: Ask the device-dependent group for example.

Use case 5.17: Response to an XML-RPC Request

Suggestion: Move this near the top two

Use case 5.18: Multiple-file command-line document generation

This is aggregation of the for-each

Alex proposes to break this into two use cases.

Use case 5.19: Database import/ingestion

Break into two use cases

Use case 5.20: Metadata Retrieval

Richard: This is a looping example

Alex: Replace 5 with "Apply this sequence of transformations"

Use case 5.21: Non-XML Document Production

Pagination in this use case really means "chunking"

Murray: The use case also works for paper markup

Alex: Is there a use case here that isn't XSL-FO?

Henry: I want a "loop until fix-point" construct

Alex: there's a use case, for example for atom, where you get the feed in chunks and I want to build the whole feed

Summary of Action Items

[NEW] ACTION: Henry to write this example for the use cases document [recorded in 27-morning-minutes.log]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/03/29 16:52:46 $