W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2003

RE: SAG-FO-04: fn:trace()

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Mon, 4 Aug 2003 14:53:11 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD015@daemsg02.software-ag.de>
To: Ashok Malhotra <ashokma@microsoft.com>, "Kay, Michael" <Michael.Kay@softwareag.com>, public-qt-comments@w3.org
I have to explain to people in my company why the task force rejected the
arguments in this comment. It would make my life a lot easier if the
response stated why the task force considers it appropriate to include
standardized diagnostic capabilities in the core function library, rather
than leaving it to implementors to design their own.

Michael Kay

> -----Original Message-----
> From: Ashok Malhotra [mailto:ashokma@microsoft.com] 
> Sent: 21 July 2003 16:16
> To: Kay, Michael; public-qt-comments@w3.org
> Subject: RE: SAG-FO-04: fn:trace()
> 
> 
> The F&O taskforce discussed this at the meeting on 7/18/2003 
> and declined to make the change you suggested.
> 
> All the best, Ashok
> 
> > -----Original Message-----
> > From: public-qt-comments-request@w3.org [mailto:public-qt-comments- 
> > request@w3.org] On Behalf Of Kay, Michael
> > Sent: Tuesday, June 10, 2003 8:50 AM
> > To: public-qt-comments@w3.org
> > Subject: SAG-FO-04: fn:trace()
> > 
> > 
> > Software AG does not believe that there is any good reason 
> to include
> > fn:trace() in the core function library.
> > 
> > We already have diagnostic features in our product that are 
> much more 
> > sophisticated and usable than the proposed fn:trace() 
> function. We do
> not
> > have a sensible way of implementing fn:trace() in our product 
> > architecture, and we believe that as a result of query 
> optimization, 
> > the output is likely
> > to be unintelligible to most users.
> > 
> > We see no need for diagnostic capabilities to be standardised. This
> should
> > be an area that is left entirely to implementors to add value.
> > 
> > We recommend that the fn:trace() function should be dropped, or at
> least
> > marked as optional.
> > 
> > Michael Kay
> > Software AG
> > 
> 
Received on Monday, 4 August 2003 09:21:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:13 UTC