Re: how to subsume or handle warnings?

Kendall Clark wrote:
> 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.


Can we use the current <link> mechanism here?  It points to some metadata for 
the results.  I don't see a need for another element as such.  Your example 
below shows that the boundary between warning and "additional information" is 
not clear-cut.

> 
> (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
> 

There remains the matter of warning for RDF/XML results over plain HTTP.  I 
don't see where addition information can be inserted.  Postponing would be 
acceptable.

	Andy

Received on Tuesday, 3 January 2006 12:11:15 UTC