Re: does DAWG actually have time to do WSDL?

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:
>>
>>> On Mar 21, 2005, at 1:12 PM, Dan Connolly wrote:
>>> [snip]
>>>
>>>> LC candidate; i.e. proposal from the editor to the WG, not from the WG
>>>> to the world. And all indications are that the QL editors are on
>>>> track for 31 Mar LC candidate.
>>>
>>>
>>> Hmm. Perhaps. It's not so clear to me.
>>>
>>>>> Things that need to be completed for protocol (IMHO):
>>>>>     1) XML syntax for query language with XML Schema description 
>>>>> (kendall
>>>>> and I are working on that; of course, bit of a moving target as the
>>>>> query language keeps changing, or potentially changing)
>>>>
>>>>
>>>> I don't see that as critical path. It's not in the charter,
>>>> not among our requirements or even objectives, and not among the
>>>> WG issues.
>>>
>>>
>>> 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. 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.

Service composition is a large, open ended area and I don't have a 
characterization of the problem as applied to SPARQL.

For example, it isn't automatically a need for an XML syntax.  We do service 
composition but by pulling out the abstraction and combining conceptualized 
services - that means abstracting away from either XML or human readable 
synatx and the presence of an XML form does not aim the process significantly.

	Andy


> 
>>  -- 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?
> 
>>>>>     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. Actually, 
> I believe that that is very similar to the xsi:type issue. So you have 
> an external and an internal person raising this issue.
> 
> Or, if you prefer, you can wait until we've completed the work with a 
> fully fleshed out proposal.
> 
> 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.
> 
> Cheers,
> Bijan Parsia.
> 
>

Received on Monday, 21 March 2005 21:12:15 UTC