W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > March 2006

Minutes for XProc WG telcon of 09 Mar 2006

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:47 GMT