RE: Comment 30, Parameter inputs as strings (was Re: Saxonica Comments on XProc last-call draft, sections 1 and 2)

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.

Michael Kay 

> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] 
> Sent: 12 October 2007 11:46
> To: Michael Kay
> Cc: public-xml-processing-model-comments@w3.org
> Subject: Comment 30, Parameter inputs as strings (was Re: 
> Saxonica Comments on XProc last-call draft, sections 1 and 2)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Kay writes:
> 
> > 7. Technical. In 2.5, Parameters, it seems unnecessarily 
> constraining 
> > to require that the value of a parameter be a string. In XSLT, for 
> > example, it is common for a parameter to have a document as 
> its value.
> 
> The Working Group discussed your comment both by email [1] and on a
> call [2].   Although your request got some support, the WG did not
> reach consensus on a proposal to add such functionality to the spec.
> The fact that XSLT itself does not require implementations to 
> support external binding of documents to parameters was 
> probably the most telling objection.
> 
> The WG did agree that the general question of managing 
> multiple input documents whose cardinality was not known in 
> advance was one we would return to for Vnext, and that any 
> solution to that problem would almost certainly address the 
> requirement which your request was intended to satisfy.
> 
> ht
> 
> [1] 
> http://lists.w3.org/Archives/Public/public-xml-processing-mode
> l-comments/2007Oct/0005.html
> [2] http://www.w3.org/XML/XProc/2007/10/04-minutes.html#item05
> - --
>  Henry S. Thompson, HCRC Language Technology Group, 
> University of Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
> 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/ [mail 
> really from me _always_ has this .sig -- mail without it is 
> forged spam] -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFHD1BfkjnJixAXWBoRAv5YAJ9r9OcC6daPjlWBUEm/dn/sQW6o8wCfW6TT
> NIhGWadr9XJ8kvCGJvQ/roI=
> =/SPn
> -----END PGP SIGNATURE-----

Received on Friday, 12 October 2007 15:05:36 UTC