XML Processing Model WG

9 Mar 2006


See also: IRC log


Alessandro, Alex, Andrew, Erik, Henry, Michael, Murray, Norman, Paul, Richard, Rui


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/03/09-agenda.html


Next meeting: 16 Mar telcon

Any regrets?

Possible regrets: Andrew, Erik

Presentation of the Arbortext pipeline

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Feb/0061.html

Andrew describes the PTC/Arbortext pipeline

XProc Requirements and Use Cases

-> http://www.w3.org/XML/XProc/docs/langreq.html

Starting with 5.22 (we ended with 5.21 at the f2f)

Norm describes the motivation for two-stage validation: structural validation followed by data-typing

Alex points out that you may actually need to give the validation a nudge

Alex: Perhaps you need some sort of scoping mechanism, to scope validation to particular elements
... e.g. for the MathML math elements, use this schema

Richard: Using a pipeline to do this rather than passing parameters to the validator

Alex: exactly

Norm: This sounds like the NVDL use case

MSM: This is useful for validation implementations that can't handle roots other than the root of the tree. But in the general case a validator may well, and perhaps will or should, allow invocation parameters that specify the desired behavior

Alex: Maybe we need to say a little more in step 4

Norm: Yes, I'll send something

Richard: It's implicit here that the pipeline fails if the validation fails

MSM: Let's make clear to our readers that this is not a necessary condition

General agreement that validation failure must not always abort the pipeline

Moving on to 5.23...

Erik: We got use cases from DSDL that might cover a lot of these multi-language situations

Alex: Those are already in our document, they'll come up later
... This is very specific, the missing detail is that this is the web service from NOAA

<MSM> Can we say 'Tag Soup or tidy' (or preferably mention a third such program)?

Alex: The initial input contains data to determine which web service to call
... Ok, I'll say TagSoup or tidy

Moving on to 5.24

The salient point here is that the description elements (and only the description elements) have to be massaged from escaped markup back into XHTML

Alex: This step exists independent of RSS

Norm: I wonder if it should be split into two use cases?

Alex: I kind of stuck them together because if you have one you need the other

Norm: I don't feel strongly about it

Moving on to 5.25

Alex: This example calls out my particular need for custom components that do strange things
... They're basically XML filters, but they perform arbitrary computations between reading XML and writing XML

Norm mumbles about tension between specificity and generality

Alex: Step 2 should probably be made a little more specific

Moving on to 5.26

Alex: I cut and pasted the wrong thing

Follow the link

Norm: The challenge that I see it is how will we turn the NVDL into a pipeline

MSM: This isn't a peephole/subtree processing sort of thing.
... There's the issue of where the leaves go and where those leaves appear as roots of verious trees
... This isn't something I think you can solve with the standard subtree mechanisms

Alex: They describe this as validation management, but it includes transformations

Richard: This pipeline is doing both validation and transformatoin
... It's far from clear to me how any of this is supposed to work at all.
... If you extract subtrees, modify them, and then try to put them back, it's not clear to me how you know where to put the transformed results back

Alex: Can we ask the submitter to clarify things?
... You can put SVG, MathML, and HTML together

Richard: Yes, but after you've transformed it, how can you tell where to put it back again?
... Without the transforms, this is just a generalization of the viewport stuff.

MSM: People who have viewport like functionality, do you have the ability to have a root in one place and a leaf in another?
... It's not quite the same

Alex: Is this something we can actually get and read?

Norm: I'll get in touch with Martin and see if we can get more of the specification and more explanation about how recombination occurs after transformation.

Moving on to 5.27

Norm: 5.27 is the standard viewport case

<richard> Alex, you have a typo in the title of 5.28 "Arbirarily"

Alex: 5.28 is different in that you don't want to load the whole tree to add some static parts
... It's an insertion operation so it's not a case of transforming part of the document

Norm: So this is like a SAX filter that inserts extra stuff

MSM: Thinking about the example of a 2gb book that we want to do in pieces.
... If you can't do forward-references, you wind up having to do multi-pass processing.
... Can we do that in a pipeline?
... Can one stage produce an .aux file that another stage reads?

Alex: Yes

MSM: At least one of the languages (XPL) supports this in a straightforward way

Richard: We aren't expecting to have any "loop until nothing changes" operators

Alex: It's hard to do this in a streaming fashion. You may really have to run the pipeline twice.
... Do you want that as a separate use case?

MSM: Yeah, sure, but it does seem a little strange since in XSLT we do have forward reference.

Norm: But not in this case, where each chapters are processed in isolation

MSM asks about memory usage; Richard asserts this is a quality-of-implementation issue in the pipeline

Alex: I would suggest this is a separate use case.

MSM: I'll write that up

Alex: I'll try to take another stab at 5.27 and 5.28 to clarify them a bit

<MSM> norm, you were distinguishing 'pipeline stage' from 'component' - for me these are synonyms, so i'm confused.

<MSM> can you expound?

Moving on to 5.29

Norm attempts to generalize 5.29 to the case where the pipeline is conditional on the available components

Richard: This might be done in a completely different way from the normal conditional expression

Alex: I'm just saying this is by analogy with the extension-element functions in XSLT

Norm suggests that a little more clarity would be good

<MSM> It might help if you said explicitly that the assumption in the use case is that not all pipeline implementations have an XSLT 2.0 component available.

Moving on to 5.30

Alex: Halt and catch fire if a custom step is unavailable

<MSM> One suggestion: make clear that the pipeline author chooses either halt and catch fire or fallback, and the requirement is that he be ABLE to choose 'die' as an option

Norm +1's MSM

<MSM> unless the intention is that this not be under pipeline author control.

Richard: Not all processors may have a "compile" stage, but we may want to write it "as if" there was a compile phase.

<MSM> never underestimate the utility of <xsl:comment terminate="yes"> (or whatever the attribute is)

Alex: I'll put together another draft of the document

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/03/28 19:40:49 $