[closed] Re: Comment 30, Parameter inputs as strings

While I personally share your concern, the WG seems determined to make them
strings.

/ Michael Kay <mike@saxonica.com> was heard to say:
| Well, it's your decision, but it seems to me that you're imposing a serious
| limitation for no good reason. You're computing the parameter value using
| XPath, which has the same type system as XSLT, so I can't see any reason to
| do any implicit type conversion - it's unnecessary and harmful. If the user
| wants a string, or if they're using an XSLT processor that only accepts
| strings, they can do the conversion themselves.
|
| One suggestion: keep your options open by thinking about how you will add
| this capability later. For example, add an <as="xs:string"> attribute with
| xs:string as the only permitted value.
|
| In the discussion I noted someone saying that when calling XSLT from the
| command line, you can often only supply a string. In fact, many command line
| processors (*) allow you to compute the parameter value with an XPath
| expression written on the command line, which enables values such as
| integers and booleans to be supplied, as well as calls on document() to
| supply a document. 
|
| (*) well, certainly Xalan and Altova. I don't know how many others.
|
| But since you've already decided to allow the value to be computed using an
| XPath expression, it really seems odd to say the value is then flattened to
| a string - especially if you've got an XSLT 2.0 stylesheet that declares the
| expected type of the parameter as something else. At the very least, please
| make it untypedAtomic so it can be converted back to an integer or boolean.

That seems uncontroversial. Done.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If you haven't found something strange
http://nwalsh.com/            | during the day, it hasn't been much of
                              | a day.--John A. Wheeler