Re: does DAWG actually have time to do WSDL?

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.

>  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;
e.g.

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

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

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


> Actually, I believe that that is very similar to the xsi:type issue.

I haven't added that to the WG issues list either.

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

Noted.

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

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


> Cheers,
> Bijan Parsia.
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 21 March 2005 22:15:56 UTC