how to subsume or handle warnings?

Folks,

Based on some protocol feedback from Graham Klyne, and some off-list  
discussion with Andy, I want to raise an issue for WG consideration.  
I think the issue should be raised, added to the issues list, and  
then postponed.

In short, should or shouldn't we have a mechanism for issuing  
warnings from a SPARQL service to consumers of that service?  
Generalizing a bit, should or shouldn't we have a mechanism whereby a  
service issues an annotation of a particular protocol operation?

These bits are *not* faults in the WSDL sense (i.e., messages that  
replace the expected Out Message of a WSDL operation), that is, they  
may be debugging messages for developers or annotations of unexpected  
results, etc. Andy gives the following examples:

  - "your query took 45ms to execute"
  - "that's a strange choice for prefix rdf:"
  - "I got a 301 trying to read that URI you FROM'ed"

I'll add:

  - "the explanation of that query results, which included inference,  
is..."
  - "the generated proof for that policy is..."

If we should, how should those warnings be communicated? The  
possibilities seem to include:

1. putting them in-band, i.e., in the results format
2. putting them out-of-band but linking to them in the results  
format; that is, conceptualizing these annotations of a protocol  
request as separate web resources and providing a link to them in the  
results format
3. putting them into the WSDL Out Message itself. (Which would mean  
different things for different bindings. In HTTP it might mean an  
HTTP header in the response or a multipart response.)

I don't believe we can use WSDL faults for this information, not only  
because faults replace messages (for the fault propagation rule we're  
using), but also because these really *aren't* faults. They're more  
like hints, warnings, notes, etc. Andy's word, 'annotations', seems a  
good umbrella term.

FWIW, I prefer a design like (2) above; the results format gets a new  
element or attribute, (say, "protocol-operation-annotation" for  
maximal legibility), which contains a URL. When dereferenced, that  
URL returns a representation of the service's annotations of a  
particular protocol operation request and response. That  
representation might be human or machine readable, which could be  
negotiated for when the URL is deref'd, and it might include none,  
some, or all of the results, plus whatever other annotating  
information the service wants to communicate.

(One reason not to put them in-band, either in the results format or  
in the WSDL Out Message, is size and complexity considerations.  
Suppose a service does optional inference explanation or proof  
checking. If you want to see the full explanation of some inferences,  
or the full debugging trace of an operation, you pass a flag and the  
service will annotate the results accordingly. But in some  
formalisms, explanations and proofs can be very large. Large enough  
and conceptually distinct enough that it makes sense, at least to me,  
to consider these web resources in their own right, give them a URL,  
and deref them when or if the client decides to.)

I also prefer to raise this issue now, perhaps discuss it, then  
postpone it till later.

Cheers,
Kendall

Received on Thursday, 29 December 2005 18:47:59 UTC