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

Just to be clear, I said

me> Having said that, I think that this interpretation is really justified
me> by the Catalogue markup 

But of course meant

   Having said that, I think that this interpretation is NOT really justified
                                                         ^^^
   by the Catalogue markup 



> As I see it, there is nothing to verify 
> since an implementation can do anything it chooses to.

I agree that from a conformance point of view trace() can be a no-op so
that the only thing that should be tested as part of a conformance or
interoperability test is the query result (which can be mechanically
tested with xml comparison). However officially the W3C doesn't go in
for conformance testing of particular systems and the purpose of the
suite as far as getting out of CR is concerned is to show that the
features are implementable, and as a general test of "have I implemented
all features" I don't mind having a few tests that make some calls on
trace() and I check by hand that they end up in the standard error
stream (or wherever I think they should go).


> 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).

Yes I agree, it would be better to use XML comparison on the expected
output and have another element <expected-trace> or something which you
could additionally verify by hand, or something....


David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Tuesday, 25 April 2006 12:51:19 UTC