- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Mon, 13 Mar 2006 15:52:39 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <871wx683u0.fsf@nwalsh.com>
See also: http://www.w3.org/XML/XProc/2006/03/09-minutes.html W3C[1] - DRAFT - XML Processing Model WG 9 Mar 2006 Agenda[2] See also: IRC log[3] Attendees Present Alessandro, Alex, Andrew, Erik, Henry, Michael, Murray, Norman, Paul, Richard, Rui Regrets Chair Norm Scribe Norm Contents * Topics 1. Accept this agenda? 2. Next meeting: 16 Mar telcon 3. Presentation of the Arbortext pipeline 4. XProc Requirements and Use Cases * Summary of Action Items ---------------------------------------------------------------------- Accept this agenda? -> http://www.w3.org/XML/XProc/2006/03/09-agenda.html[4] Accepted 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[5] Andrew describes the PTC/Arbortext pipeline XProc Requirements and Use Cases -> http://www.w3.org/XML/XProc/docs/langreq.html[6] 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 [End of minutes] ---------------------------------------------------------------------- [1] http://www.w3.org/ [2] http://www.w3.org/XML/XProc/2006/03/09-agenda.html [3] http://www.w3.org/2006/03/09-xproc-irc [4] http://www.w3.org/XML/XProc/2006/03/09-agenda.html [5] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Feb/0061.html [6] http://www.w3.org/XML/XProc/docs/langreq.html [7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [8] http://dev.w3.org/cvsweb/2002/scribe/ Minutes formatted by David Booth's scribe.perl[7] version 1.127 (CVS log[8]) $Date: 2006/03/13 20:47:44 $ 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 Monday, 13 March 2006 20:53:00 UTC