W3C

XML Processing Model WG

Meeting 47, 14 Dec 2006

Agenda

Attendees

Present
Norm, Richard, Henry, Paul, Mohamed, Rui, Alex, Andrew, Michael
Regrets
None
Chair
Norm
Scribe
Norm

Contents


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"/>

<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

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]

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