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.

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

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

<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