- 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 UTC