Re: Use cases for XML serialization

On Mar 23, 2005, at 5:02 AM, Seaborne, Andy wrote:

> Bijan Parsia wrote:
>> For Howard(?), I restate (I hope concisely) some use cases for XML 
>> Serialization:
>> 1) I think for a good WSDL for SPARQL, having an XML Schema type for 
>> specifying the input and output messages in the abstract interface is 
>> highly desirable. This generates, as a side effect, and XML 
>> serialization.
>> 2) I think for actual bodies of SOAP messages, XML is preferable. I 
>> guess, in general, embedding XML in XML formats is better than 
>> embedding strings in other formats. Especially if validatable.
>
> Agreed - with the caveat that this is the long term goal and is not a 
> prequistie for SPARQL version 1.
>
> (This is very true for query services such as query brokering - which 
> was one example of service composition given.  We can declare vistory 
> for SPARQL v1 without having solved the query brokering and federation 
> dimension.)

SPARQL the query language or SPARQLP. I agree strongly with it for the 
former, for the latter I think it's both achievable and important to 
get it out early.

Let me be more precise. I think it's very important to have WSDL for 
the protocol (obviously). If adding a SOAP binding of any sort would 
delay significantly the protocol, then I would be find just relesaing 
the get oriented HTTP binding and saving the other bindings for future 
work (this kind of modularity is an advantage of WSDL). However, for 
good WSDL, I strongly feel we need the XML Scheme types for the 
abstract interface. Once we have that, we have a serialization format 
in XML. Once we have that, the requisite SOAP binding follows easily.

This has the further advantage of forestalling ...er...Mark Baker's? 
(with someone else) comment about validating the abstract interface 
with at least two bindings.

>> 3) I was already generating a XML format in order to support legacy 
>> applications with say, RDQL, Versa, and SeRQL services. I prefer 
>> generating XML from a SPARQL query, and using XSLT or XQuery to 
>> generate RDQL or other query languages.
>
> Doesn't that put a another requirement on the SPARQL.xml syntax?  It 
> now needs to work with RDQL, Versa, and SeRQL as well.

I don't believe so. It might be nice to have extensibility points to 
add features (both for future us work, and for other languages), but I 
think there's a large overlap between the languages and many of my 
queries fall into that overlap. Having and XML format makes managing 
those common and legacy cases easier even without specific support for 
the target languages.

>> 4) Having schema (which entails XML serialization) allows us to 
>> express what parts of the query language a server does or does not 
>> support for various datasets (or all of them). So I can, I believe, 
>> restrict the query to only allow select queries if I don't support 
>> ask, describe, or construct *without* the working group having to 
>> define any conformance levels.
>
> This one suprised me.  I would expect the service description to 
> include this information but also features that are not syntactic, 
> like extension functions support, or vocabularies used in datasets.

Yep. But some of it can be specified in the type signatures, 
particularly, when such restrictions are on base features of the query 
language. If Kendall and I can get it to work for functions supported 
in filter, I'll be even more happy.

>   In other words,I expected one framework for this and, as it is not 
> all syntactic, I was expecting it not to be tied to any syntax.

Well, in WSDL, and most SWS frameworks like OWL-S, some of these things 
are specified in the functional signature, and some in the rest of the 
description. In my experience, the more we can push into the types the 
better. They work with a wider range of tools (some composition, many! 
composition, and many matchmakers for Web Services work either solely 
or primarily with IO type), and in can often significantly increase 
quality and performance of these tools.

> 	Andy
>
>> There are others, but I hope this is a good start. (Am I trying to 
>> convince people, or trying to generate something for the use case 
>> document?)
>
> I found it helpful - thanks.

My pleasure.

FWIW, as well, none of these were hypothetical for me. I intend to do 
some variant of all of these. Actutally, number 3 was something kendall 
and I needed for a survey paper.

Cheers,
Bijan.

Received on Wednesday, 23 March 2005 16:28:00 UTC