Re: LC 323 thoughts

Hi, 

I think this is a very good summary of our options. My view is that
SPARQL in fact does have multiple operations (most probably the four as
described in point two below) so we should tell DAWG to model their
interface that way. This will allow semantic description of the
operations as well later.

But we still may consider allowing multiple different output content
types if we find a use case where we'd agree a single operation can have
multiple different output content types. How about HTTP GET? Yes, plain
HTTP GET is what I mean. 8-)

But as long as such a use case is not logged as an LC issue (and don't
log mine, I'm not pushing it in any way), I feel we shouldn't spend much
time on it.

Best regards,

Jacek





On Thu, 2005-09-08 at 10:12 -0700, David Orchard wrote:
> For LC 323
> http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC323
> 
>  
> 
> The gist of this was raised at
> http://lists.w3.org/Archives/Public/www-ws-desc/2005Aug/0010.html
> 
>  
> 
> I think that they have a valid point.  The xml media types allow a
> notion of "specialization", where media types can be related by
> restriction.  In their example, they have two legitimate return media
> types that are both +xml, that is sparql-results+xml and rdf+xml.
>  They have a single "query" operation and they want to be able to
> describe both.  Further, they can have "faults" in multiple media
> types.
> 
>  
> 
> I think the crux of the matter is whether we see a URL that returns
> multiple media types as conceptually one operation with multiple
> "return types" or one operation per media type that are overloaded on
> one url or even one operation per input that returns a distinct media
> type.  I see pros and cons of these views, but I worry that the one
> operation complicates the conceptual view of the binding.  
> 
>  
> 
> There are 4 solutions that I see:
> 
>  
> 
> 1. Two different query operations that each have their own return
> media type and then are deployed at the same url.  As jacek mentioned,
> query operation has to fulfill the "operation name mapping"
> requirement.  I'm not sure if this would also work for fault media
> types, but probably.
> 
>  
> 
> Looking at their scenario, I think that a WSDL author that didn't know
> or worry about media types that allowed two different return "types"
> would define a different operation for each type, ala "get sparql" and
> "get rdf".  Deployed at the same URL, the qname (either rdf or
> sparql-results) of the return value will tell them what "they got".  
> 
>  
> 
> 2.   Four different query operations that each have their own return
> media type and then are deployed at the same url.  The sparql queries
> have well defined rules for which media type will be returned based
> upon the input query type.  I *think* they have actually defined about
> 4 query types.  So they could define 4 operations:
> 
> Select returns sparql-results
> 
> Ask returns sparql-results
> 
> Describe returns rdf+xml
> 
> Construct returns rdf+xml 
> 
>  
> 
> 3. force them to return only application/xml
> 
>  
> 
> 4. update WSDL to allow multiple output media types.  
> 
>  
> 
> To a certain extent, this is about how strong the operation typing is,
> ranging from "query in" and "xml out" to "Select input" and
> "sparql-out", and if any association between the input and output
> types should be in wsdl or not.
> 
>  
> 
> I think they are effectively asking the WSDL group "How many wsdl
> operations are there", and we should provide them an answer.
> 
>  
> 
> I'll observe that their scenario may be "easy" in that there are a
> small # of return type discriminators, and other applications could
> have a very large # of discriminators.  
> 
>  
> 
> Cheers,
> 
> Dave
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>

Received on Thursday, 15 September 2005 14:33:46 UTC