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

Re: More defaulting

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 30 Apr 2007 07:44:12 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87vefexf1v.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I don't view this as defaulting:

Fair enough. I should have said syntactic sugar, I guess.

| So what I'd propose is:
| (1) Options are set by attributes on steps, which may contain {}s to
| indicate evaluated content
| (2) We provide a <p:variable> element to create lexically-scoped
| variables that can be declared and used anywhere within the pipeline
| (3) <p:option> is only used to declare options, at the start of
| <p:pipeline> (it has the same relationship to <p:variable> as
| <xsl:param> has to <xsl:variable>)
| The example above could then be written:
|   <p:variable name="root1" select="name(/*)">
|     <p:pipe step="step1" source="result" />
|   </p:variable>
|   <p:variable name="root2" select="name(/*)">
|     <p:pipe step="step2" source="result" />
|   </p:variable>
|   <my:example root1="{$root1}" root2="{$root2}" />
| Compound steps (<p:for-each>, <p:viewport>, <p:group> etc.) could no
| longer contain <p:option>.

That's a much larger and more significant change than I had in mind. I
was just suggesting a little syntactic sugar. Adding attribute value
templates and p:variable into the mix (along with p:option and
p:parameter) and removing options from compound steps all sounds like
far to high a cost (to me) to justify a little less typing.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | Why in our youth does the life we still
http://nwalsh.com/            | have before us look so immeasurably
                              | long? Because we have to find room for
                              | the boundless hopes with which we cram
                              | it.-- Schopenhauer

Received on Monday, 30 April 2007 11:44:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC