Discussion: fn:error has cumbersome signature

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion: fn:error has cumbersome signature

frans.englich (Bugzilla)

Hello all,

I'm thinking about the fn:error function from an implementation perspective.
It's not enough(at least not yet) for raising an issue for the WG.

fn:error have the following signatures:

fn:error() as none
fn:error($error as xs:QName) as none
fn:error($error as xs:QName?,
         $description as xs:string) as none
fn:error($error as xs:QName?,
         $description   as xs:string,
         $error-objects item()*) as none


From what my memory recalls, it is the only function that have different
arguments depending on the amount of arguments, `error as xs:QName` is
sometimes of cardinality zero or one, sometimes exactly one. My estimate is
that this is cumbersome for implementors to implement because the different
signatures can't be handled in a uniform way, but is exceptional(it is at
least cumbersome in my case, and by a broad look at Saxon's design, in that
case too). From a user perspective I would also claim it is confusing to
alter a signature by more than adding new arguments.

After a quick look at Saxon's Error.java and StandardFunction.java, it looks
like Saxon does not trigger "error( () )" as a type error, but accepts it,
which also is confirmed by running the expression in a stylesheet.

I would prefer if the second signature, "fn:error($error as xs:QName) as
none", had its argument's cardinality changed to '?'. If it wasn't for the
wording "If the first argument in the third or fourth signature is the empty
sequence it is assumed to be the xs:QName constructed by: [...]" I would have
guessed it was a typo in the signature.

I would like to submit a better alternative, but don't know exactly what to
take into account.

Anyone knows the reasoning behind why the signature looks like it does? E.g,
what justified this exceptional design?


Cheers,

                Frans



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: fn:error has cumbersome signature

Colin Paul Adams
>>>>> "Frans" == Frans Englich <[hidden email]> writes:

    Frans> I would prefer if the second signature, "fn:error($error as
    Frans> xs:QName) as none", had its argument's cardinality changed
    Frans> to '?'.

Why?
Apart from the need I feel to put a smiley in the error message?
--
Colin Adams
Preston Lancashire


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: fn:error has cumbersome signature

frans.englich (Bugzilla)
On Sunday 11 September 2005 15:03, Colin Paul Adams wrote:
> >>>>> "Frans" == Frans Englich <[hidden email]> writes:
>
>     Frans> I would prefer if the second signature, "fn:error($error as
>     Frans> xs:QName) as none", had its argument's cardinality changed
>     Frans> to '?'.
>
> Why?
> Apart from the need I feel to put a smiley in the error message?

For the reasons given above: to not have this exceptional signature, in order
to reduce surprises for users and, what I claim it also would do, reduce
implementation barrier(make it simpler). I'm not claiming I know the absolute
truth on this, that's why I posted it here for discussion, so different
opinions is of interest, of course.

One can phrase it in a different way: Why not make the second signature's
argument's cardinality zero or one? Would the broadening of the parameter be
that bad?

Another alternative afaict is to switch the arguments, that the xs:QName is
the last argument in the third and forth signature. But that leads to other
trouble.


Cheers,

                Frans


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: fn:error has cumbersome signature

Colin Paul Adams
>>>>> "Frans" == Frans Englich <[hidden email]> writes:

    >>  Why?  Apart from the need I feel to put a smiley in the error
    >> message?

    Frans> For the reasons given above: to not have this exceptional
    Frans> signature, in order to reduce surprises for users and, what

What surprise? The documentation is clear enough - and surely error (
() ) HAS to be a user error.
 
    Frans> I claim it also would do, reduce implementation
    Frans> barrier(make it simpler).

I found no problems implementing this.
--
Colin Adams
Preston Lancashire


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

RE: Discussion: fn:error has cumbersome signature

Michael Kay
In reply to this post by frans.englich (Bugzilla)
Functions are identified by the combination of name and arity; there's
therefore no logical necessity for error(x) and error(x,y) to have any
relationship to each other either in their signature or in their semantics.
The fact that Saxon internally exploits the fact that in most cases there is
some relationship isn't going to cut any ice with the WG.

The Saxon mechanism for looking up an implementation of a system function
does in fact allow the signature to vary with the arity. The mechanism is
used for string-length and normalize-space - though as far as I can tell
it's there only for historical reasons (whose details escape me).

For the error() function, the signature is a wee bit academic since it's
going to throw an error whatever arguments you give it; hence the slightly
loose implementation of the signature in Saxon. From an implementor's
perspective my only real problems in handling this function are in handling
its unusual return type.

There's always scope for dotting a few more i's in the spec. The WG is now
tending to ask the question "does anyone want to delay CR in order to get
this fixed?", and for this one I suspect no-one would stick their hands up
to say yes.

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Frans Englich
> Sent: 11 September 2005 15:30
> To: [hidden email]
> Subject: [saxon] Discussion: fn:error has cumbersome signature
>
>
> Hello all,
>
> I'm thinking about the fn:error function from an
> implementation perspective.
> It's not enough(at least not yet) for raising an issue for the WG.
>
> fn:error have the following signatures:
>
> fn:error() as none
> fn:error($error as xs:QName) as none
> fn:error($error as xs:QName?,
> $description as xs:string) as none
> fn:error($error as xs:QName?,
> $description   as xs:string,
> $error-objects item()*) as none
>
>
> From what my memory recalls, it is the only function that
> have different
> arguments depending on the amount of arguments, `error as
> xs:QName` is
> sometimes of cardinality zero or one, sometimes exactly one.
> My estimate is
> that this is cumbersome for implementors to implement because
> the different
> signatures can't be handled in a uniform way, but is
> exceptional(it is at
> least cumbersome in my case, and by a broad look at Saxon's
> design, in that
> case too). From a user perspective I would also claim it is
> confusing to
> alter a signature by more than adding new arguments.
>
> After a quick look at Saxon's Error.java and
> StandardFunction.java, it looks
> like Saxon does not trigger "error( () )" as a type error,
> but accepts it,
> which also is confirmed by running the expression in a stylesheet.
>
> I would prefer if the second signature, "fn:error($error as
> xs:QName) as
> none", had its argument's cardinality changed to '?'. If it
> wasn't for the
> wording "If the first argument in the third or fourth
> signature is the empty
> sequence it is assumed to be the xs:QName constructed by:
> [...]" I would have
> guessed it was a typo in the signature.
>
> I would like to submit a better alternative, but don't know
> exactly what to
> take into account.
>
> Anyone knows the reasoning behind why the signature looks
> like it does? E.g,
> what justified this exceptional design?
>
>
> Cheers,
>
> Frans
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: fn:error has cumbersome signature

frans.englich (Bugzilla)
On Sunday 11 September 2005 17:51, Michael Kay wrote:
[...]

> There's always scope for dotting a few more i's in the spec. The WG is now
> tending to ask the question "does anyone want to delay CR in order to get
> this fixed?", and for this one I suspect no-one would stick their hands up
> to say yes.

Yes, I agree. While it would perhaps be possible to conclude the signature
could be improved, it's a too intrusive change at this stage of development.


Cheers,

                Frans


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help