RE: does DAWG actually have time to do WSDL?

Dan,

I feel that the expected benefit of a solid protocol solution warrants
further attention to the proposals for the use of WSDL.  I also feel
that the XML serialization warrants attention even in the absence of
its use with WSDL.  We place to generate and consume it in our tool.

-bryan

-----Original Message-----
From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
On Behalf Of Bijan Parsia
Sent: Monday, March 21, 2005 5:51 PM
To: Dan Connolly
Cc: Kendall Clark; DAWG Mailing List; Eric Prud'hommeaux; Hugo Haas;
Philippe Le Hegaret
Subject: Re: does DAWG actually have time to do WSDL?



On Mar 21, 2005, at 5:15 PM, Dan Connolly wrote:

> On Mon, 2005-03-21 at 14:59 -0500, Bijan Parsia wrote:
>> On Mar 21, 2005, at 2:21 PM, Dan Connolly wrote:
>>
>>> On Mon, 2005-03-21 at 13:27 -0500, Bijan Parsia wrote:
> [...]
>>>> I think it implicit in using WSDL.
>>>
>>> Our discussion was fairly explicit to the contrary:
>>>
>>>     <xs:element name='queryString' type='xs:string'/> <!-- in, e.g., 
>>> SPARQL syntax -->
>>
>> I'm sorry, I didn't realize that had force instead of being merely a 
>> straw proposal for discussion.
>
> It was just a straw proposal for discussion.
>
> But I understand the requirement to be about writing a WSDL 
> description for the protocol that's equivalent to these HTML forms...
>
>   http://sparql.org/query.html
>   http://librdf.org/query?language=sparql
>
> and is given in the 1st example in 
> http://www.w3.org/2001/sw/DataAccess/proto-wd/
>
> There's no XML serialization of the query needed for that.

You might want to check some of my prior messages. XML Schema is the 
native, and only supported, type system for the abstract section (aka 
interfaces). So the *specification* of the IO of an operation is done 
with XML Schema.

The *binding* can map that XML Schema to arbitrary wire 
formats/protocol things (pretty much). Look at the HTTP binding for an 
example in terms of GETted uris.

>>  People were having enough trouble with
>> the WSDL (which was novel to most) that I didn't think it was a good 
>> point to raise then.
>>
>> I raise it now. That essentially makes the input untyped which is 
>> very very unfortunate for a slew of reasons that I have enumerated 
>> elsewhere. It looks especially odd given that we have an XML output 
>> syntax.
>>
>> One thing I may not have mentioned is that it make useful service 
>> composition very difficult to impossible.
>
> Hmm... I haven't had that experience; on the contrary, service 
> composition seems trivial using string queries;

How do you distinguish (at at least the abstract level) all the 
services that consume sparql queries as opposed to rdql queries?

> e.g.
>
> "Example of Using Rasqal to query SPARQLer's RDF/XML constructed 
> result to find just the book titles"

This requires all the composed services to be uniform. Of course if you 
want to compose services for which you know all the relevant details 
from prior, out of band, arrangemetns, it's easy. The harder part is if 
you want the services to be self-describing to systems without prior 
understanding of them.

> <-- http://esw.w3.org/topic/DawgShows
>
>
>>>  -- http://www.w3.org/2001/sw/DataAccess/ftf5-bos.html#item_03
>>>
>>>
>>>>> I'm not inclined to add it to the issues list. If there's support
>>>>> for
>>>>> it as a requirement from more than one WG member, I suspect I'll
>>>>> discover that in due course (perhaps as a comment on this week's
>>>>> agenda) I haven't followed the thread closely, since, as I say, 
>>>>> it's
>>>>> not on our critical path.
>>>>
>>>> Well, I've argued why it is important to the protocal document, at 
>>>> length. I've been sick so I've not replied to the very end of the 
>>>> thread, but I saw nothing directed substantially to my arguments.
>>>
>>> Silence doesn't imply agreement... especially for things that aren't 
>>> on our agenda.
>>
>> I didn't say, nor did I imply, it did. To be clear, I'm unsure what 
>> else I am to do to advance this point. I guess I need to get someone 
>> to show some support on list?
>
> Right.
>
>
>>>>>> 	2) Sensible XML Schemable XML output format (I thought this was
>>>>>> the
>>>>>> same as the xsi:type discussion, but I'm happy to raise a separate
>>>>>> issue).
>>>>>
>>>>> That's on the editor's TODO list...
>>>>> "ACTION DaveB: to consider use of xsi:dataType ala comment from 
>>>>> Steer"
>>>>>
>>>>> but there isn't a WG decision in the critical path.
>>>>
>>>> I would like to raise having a fully W3C Schemable XML syntax for 
>>>> results, then.
>>>
>>> As I say, I'm not inclined to add it to the issues list unless/until 
>>> there's more support.
>> [snip]
>> Why? As a working group member, I am raising this as an issue.
>
> Adding it to the issues list puts another WG decision between us and 
> last call. I'm not convinced that's merited. It seems that we can 
> advance the state of the art and meet our charter and requirements 
> without an XML seriazliation for the query language.

 From the protocol perspective, the most important part is the type, the 
second most important part is the serialization of that type since it 
allow for what I'll call "more normal" SOAP usage. Fortunately, to do 
one is pretty much to do the other.

> Our process to date is ...
> "Issues are accepted by the chair and disposed of by WG decision."
> -- http://www.w3.org/2001/sw/DataAccess/issues

Well, what if I strongly disagree with the chairs lack of acceptance? I 
guess a last call comment is still possible.

>> Actually, I believe that that is very similar to the xsi:type issue.
>
> I haven't added that to the WG issues list either.

I didn't realize that either.

>>  So
>> you have an external and an internal person raising this issue.
>
> Noted.

I will try to gather futher indications of support. I'd be interested 
to know what the threshold is.

>> Or, if you prefer, you can wait until we've completed the work with a 
>> fully fleshed out proposal.
>
> What I'm waiting for is an indication that other WG members think this 
> should be critical path.
>
> The clearest indication would be if they found it worth implementing. 
> I'd very much like to turn the corner away from "this is a very 
> important feature" to "the way I implemented it doesn't seem to quite 
> match the way you implemented it, and the spec doesn't clearly say 
> who's right an who's wrong..."

Does it have to be working group members? What if it is, for example, 
our partners? Fujistu labs is just waiting for us to get the WSDL done 
to migrate their implementation.

>> I'll raise another small complexity: The psuedo-wsdl tried to have a 
>> union type of a (presumably) w3c schema type and a relax ng type (for 
>> the output, to capture bindings and rdf graphs). This would require 
>> an extension to WSDL as it stands. One possible solution is to back 
>> translate everything to relax. Another would  be to accept a less 
>> restrictive syntax for RDF/XML, which may be more acceptible, given 
>> that if you accept RDF/XML at all, you have to do a lot of work 
>> outside of any schema language I know of. *AND* that people accepting 
>> RDF/XML accept that.
>
> Yes, that wrinkle came up in Boston. While the ideal solution probably 
> involves changing WSDL, it seems straightforward to get close enough 
> just by using less restrictive types.

Can we put this to the group? If so, it's in on sense one less thing 
and in another one more :)

Cheers,
Bijan.

Received on Tuesday, 22 March 2005 00:45:00 UTC