W3C home > Mailing lists > Public > public-xqts-comments@w3.org > April 2006

Re: Inspect/implementation defined order fn-trace-*

From: Frans Englich <frans.englich@telia.com>
Date: Tue, 25 Apr 2006 11:00:19 +0000
To: David Carlisle <davidc@nag.co.uk>
Cc: public-xqts-comments@w3.org
Message-Id: <200604251100.19366.frans.englich@telia.com>

On Tuesday 25 April 2006 10:11, David Carlisle wrote:
> Frans,


> I think (as a non WG member) that the reason these are Inspect is that
> the point of trace() is that you need to _inspect_ the trace output
> (which has gone to some system specific place).
> The actual result returned by the query isn't system dependent, but
> it's for you to look at the log generated by the trace() function and if
> it's empty or if it just says "system error: couldn't write to log file"
> or something else other than the expected trace, it's for you to decide
> whether that constitutes a pass or fail.
> Having said that, I think that this interpretation is really justified
> by the Catalogue markup which does, as you say, imply that one should
> manually compare the result output with the supplied result file.
> The Catalogue format should probably be extended to allow the Catalogue
> to specify both the Query result (checked by XML comparisopn) and the
> trace log (checked by inspection).

I don't see what the XQTS can do in order to verify interoperability on the 
trace. The destination is ·implementation-defined·, the format is 
·implementation dependent·, the ordering between multiple invokations is 
·implementation dependent·, and not the least that the data "may be directed 
to a trace data set". I see nothing which an implementation is required to 
do, not even to report anything. As I see it, there is nothing to verify 
since an implementation can do anything it chooses to.

So, let's say the tests are of type 'Inspect' in order to somehow verify/test 
the trace output, it currently happens at the cost of that the data output is 
not fully verified(well, it depends on inspection).

So, the alternatives are to either extend the catalog as you describe, or to 
skip anykind of validation of the trace output. I think the latter is the 
right one, because trace is implementation defined.


Received on Tuesday, 25 April 2006 10:48:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:39:04 UTC