Re: Describing parameters

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Hi,
|
|> Please review Section 4.2.4[1] of the alternate draft. (Nothing else
|> has changed in that draft.)
|
| Four things:
|
| 1. I think I'm right in saying that the only place where required="yes|no" is
| useful is on <p:parameter> directly within <p:pipeline>; in all other cases,
| parameters must be assigned a value.

I would have thought that it made sense on a declare-component-type.

| Given that assigning an actual value and
| assigning a default value are done in exactly the same ways, I think it would
| make sense to merge the identical parts of 4.2.4.1 and 4.2.4.2, something like:
|
|  4.2.4 p:parameter Element
|  4.2.4.1 Declaring Parameters
|  4.2.4.2 Using Parameters
|  4.2.4.3 Assigning Values to Parameters

Sure. Editorially, I'm not real content with the current text.

| 2. In many cases, the value of a parameter will be derived from other parameters
| rather than from an input. Therefore, I think the various ways of identifying a
| context document (step+source, href, here document) should be optional rather
| than mandatory.

I see what you mean. Actually, we have this little wrinkle right now where

  <p:parameter select="/foo"/>

isn't an error (as I think it should be) but is instead an attempt to
access /foo in an empty here document. I don't know if that's worth
fixing or simply documenting.

| In fact, I think I would prefer to mandate that one of 'select'
| or 'value' must be specified unless the <p:parameter> is a child of <p:pipeline>
| (and perhaps even mandate that one of 'select', 'value' or 'required' must be
| specified).

Yes, we could do that.

| 3. I'm really not sure about the value of 'here' documents when setting
| parameters. Why would you ever do:
|
|   <p:parameter name="foo" select="/foo/@bar">
|     <foo bar="baz" />
|   </p:parameter>
|
| when you could do:
|
|   <p:parameter name="foo" value="baz" />

Fair enough. I only allowed here documents for consistency. Maybe for
parameters they should not be allowed.

| 4. It strikes me that the functionality of <p:import-parameter> could be
| supported using <p:parameter>. We could allow:
|
|   <p:parameter name="*" />
|
| within a step to mean "pass in all the in-scope parameters". Just as when
| declaring a parameter, if the name attribute doesn't hold a QName then you can't
| specify a value for the parameter.

If the functionality of import-parameter survives, I think this sounds
like a good idea.

| 5. I know that we made a decision to use "parameter" rather than "param" because
| we're not using abbreviations elsewhere, but I'm *so* used to writing "param"
| dammit! (As will be most XSLT users.) And "input" and "param" line up so nicely!

Yeah. Personally, I could go back to param too, except that I find I
type xsl:param awfully frequently :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.