See also: IRC log
-> http://www.w3.org/XML/XProc/2006/03/09-agenda.html
Accepted
Any regrets?
Possible regrets: Andrew, Erik
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Feb/0061.html
Andrew describes the PTC/Arbortext pipeline
-> 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