XML Processing Model WG

Meeting 47, 14 Dec 2006



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


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


Accept minutes from the previous meeting?

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


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


Here's a for-each:

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

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

<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 name="xform-to-html" type="p:xslt">

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

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



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

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


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]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/12/21 17:12:44 $