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

XProc Minutes 14 Dec 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 19 Dec 2006 15:28:31 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87d56fiqa8.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/12/14-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 47, 14 Dec 2006

   Agenda[2]

Attendees

   Present
           Norm, Richard, Henry, Paul, Mohamed, Rui, Alex, Andrew, Michael

   Regrets
           None

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 21 Dec 2006?
         4. Standard components
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/12/14-agenda.html

   Norm: I'd like to ask a few questions about last week

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/12/07-minutes.html

   Accepted.

  Next meeting: telcon 21 Dec 2006?

   Any regrets? None given.

   Norm: Regarding the nested input/output/parameter story.

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

   Norm: Was there any discussion of the fact that there seem to be some
   wrappers missing in Murray's proposal?
   ... e.g., he shows p:internal directly as a child of p:when.

   Moz: On the p:when element, there is only one interal input for testing.

   Alex: I see what you mean.

   Henry: I think Murray just moved the attributes down into one of the three
   elements.

   Norm: I find that exceptionally unsatisfying, am I alone?

   Henry: No, I hadn't thought it through.

   Norm: If Murray arrives, I'll ask him, otherwise the editor will do his
   best.

   Henry: We'll have to give a fixed name to the XPath input, as we do for
   the iterator input.

   Some discussion of the for-each and viewport case

   Nevermind.

   Here's a for-each:

   <p:for-each name="chapters" select="//chapter">

   <p:input port="source" href="http://example.org/docbook.xml[6]"/>

   <p:output port="html" step="xform-to-html source="result"/>

   <p:output port="fo" step="xform-to-fo" source="result"/>

   <p:step name="xform-to-fo" type="p:xslt">

   <p:input name="source" step="chapters" source="current"/>

   <p:input name="stylesheet" href="fo/docbook.xsl"/>

   </p:step>

   <p:step name="xform-to-html" type="p:xslt">

   <p:input name="source" step="chapters" source="current"/>

   <p:input name="stylesheet" href="html/docbook.xsl"/>

   </p:step>

   </p:for-each>

   Richard: The point is that there's no p:input with name='current' there.

   Norm: Right.

   Henry: We could roll-back our decision about when/choose and say that we
   make an analgous requirement.
   ... That there must be an input whose port is test.
   ... Just as for-each has an implicit signature that says you have to bind
   something to 'source', choose/when could say you have to bind something to
   a 'test' port.

   <MSM> [Er, Norm, is your example tied to a change in the definition of the
   scope rules?]

   Michael: Scope rules in the current draft don't allow the names of the
   outputs to be seen by the steps.

   Henry: What Michael believes is that the outputs of the steps are not
   available for the outputs of the for-each ot refer to.

   Norm quotes the draft to the contrary.

   Richard: I'm a little unsure about how this works for choose.
   ... It seems like there needs to be some virtual output.
   ... I don't think there's a serious problem here, I'm just a little
   unhappy with the wording.
   ... It's not the outputs, its the set of names

   Norm: Right. I've changed the context to be explict about the fact that
   these are names.

  Standard components

   The current draft says: identity, xslt, xinclude, serialize, parse, load,
   and store are all standard components.

   Norm: Any others?

   MoZ: Validate

   Michael: With some language or any language?

   Mohamed: I think that needs to be discussed.

   Norm: I thought may be we needed that one too, then I thought maybe that
   was setting awfully high.

   Richard: For XSD, RNG, and Schematron would certainly set the bar awfully
   high.
   ... Only one might be ok, but it would have to be XSD

   Norm: The XSLT 2 processor doesn't require validation

   Alex: Right, I think it has to be optional.

   Richard: A virtual validate component to which you could provide a set of
   schemas in any languages and it could do one.

   Norm: Let's not.

   Michael: No one has mentioned DTDs.

   Richard: I didn't include them because of few systems that allow you to do
   DTD validation once you have an infoset.

   Mohamed: What about putting this on the load component?

   Henry: Can you get any guarantees about external entities, for example.
   ... I'd like to put a marker down to say that you might like to be able to
   request/require DTD validation on the way in.

   Richard: Coming back to a validate component, one alternative would be to
   allow the author to say that an identity transform is done if a component
   is unavailable.

   <MSM> [Richard: good point. I know of one, but only one, namely xmllib --
   at least, it has a way of validating on a tree, according to its options
   list]

   Alex: I wonder if some of the stuff with validate points to the need to
   have some sort of require statement for components.

   Richard: I would expect it to work the other way around by default, to
   fail if a component is not available.
   ... I'd prefer that we had more explicit processing mechanisms rather than
   implicit ones.
   ... Murray wants fallback for unavailable hrefs.

   Norm: I don't want any of this complexity for V1!!!

   <MSM> [Is fallback-to-alternate data stream really the same as
   fallback-to-alternative-subpipeline ?]

   Alex: We have a requirement to fallback from, for example, XSLT 2 to XSLT
   1

   Richard: In C, you have cpp that is often implemented as a separate
   program.
   ... We could do this with a pipeline that runs on your pipeline.

   Alex: I think it's reasonable to point out that there are lots of ways to
   run a pipeline, for V1 maybe we don't need to do more than let the
   application deal with it.

   <Zakim> MSM, you wanted to ask (after this discussion dies off) what we
   will use to drive ourselves to work out how type annotations work in
   pipelines, if XSD validation is not a required

   Michael: I'd like it if we had a mechanism to assure that we have a
   coherent story about type annotations. The one thing that worries me about
   making validation components completely optional is that it provides a
   convenient loophole to slip through and fail to that thinking.

   Norm: I think we've already avoided that question.
   ... by saying that what flows between components is up to the application

   Norm observes that this was a question at the XML 2006 panel

   <alexmilowski>
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/att-0042/standard-components.html[7]

   Norm: Anyone else have any required components to nominate?

   Henry: At the risk of opening a difficult topic, we already have the load
   component on the list.
   ... that's what we need to deal with external inputs.
   ... but I don't think we have the here component.
   ... We've previously discussed the idea that all inputs are from pipes.
   ... We have a story for inputs from other components and hrefs, but not
   for "here" documents.

   Alex: I don't understand how what we have doesn't suffice.

   Henry: The same argument would go for the load component.

   Alex: I kind of agree with you. But other people want to be able to load
   things specified by parameters.

   Norm attempts to summarize the situation

   Alex: I think we have lots of bases covered, I'd rather get rid of the
   load component completely.

   <ht> I'd much rather have both than neither, independently of whether we
   express the semantics in terms of them or not

   Alex: I'm reluctant to add more core components unless we find that
   there's something missing

   <ht> I think the arguments for a 'here' component is similar to the one
   for 'load' -- you want to say something once that you plan to use in
   several places

   Richard: Maybe I've missed something. The Load component does something
   that the input element can't do; so it's more general.
   ... If you wanted to be able to do that, then it makes sense to define the
   ordinary input in terms of that component.

   <ht> scribenick: ht

   <MSM> [Me notes a terminological issue: anyone with the name of the QT
   'serialization' spec in their head will expect the serialization component
   to do what the store component does. I don't think I have an alternative,
   though.]

   RT: We shouldn't define the semantics of URI reference twice -- we should
   define input/@href in terms of the 'load' component

   AM: Disagree strongly, we should define each of them where they are,
   making input/@href depend for its meaning on 'load' is possible, but will
   just confuse people
   ... We could do it the other way, that is, define 'load' in terms of
   input/@href

   RT: But you can specify the URI via a parameter to 'load'

   AM: I'm talking about the eventual result semantics

   HST: I prefer having both components to neither

   AM: How is it different from identity?

   HST: Oops, right, if it has its own syntax it has to be a primitive not a
   component

   RT: Isn't the 'parse' component what we're talking about?

   AM: No, it's input is a single element containing a string to be parsed
   ... There's a separate discussion about load/store vs. parse/serialize,
   for ATOM

   HST: Or NEWSML

   NW: Please start that thread

   AM: I'm done with that, not the right person to start the thread

   NW: OK, I will do that

   RT: I don't dislike the component, but I'd like to retain the wrapping
   element. . .
   ... There's the issue of the brokenness of lots of quoted XML

   NW: That's why I'm not a supporter of this

   AM: Summarises [scribe missed the three points]

   NW: Also, what are the microcomponents

   <alexmilowski> 1. the "here" construct

   <alexmilowski> 2. whether parser/serialize should be core

   <alexmilowski> 3. how parse/serialize should work

Summary of Action Items

   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/12/14-agenda.html
   [6] http://example.org/docbook.xml
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/att-0042/standard-components.html
   [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [9] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[8] version 1.127 (CVS
    log[9])
    $Date: 2006/12/19 20:22:58 $

Received on Tuesday, 19 December 2006 20:24:45 GMT

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