There is an open issue against SOAP 1.2 regarding the suitability of SOAP, and the SOAP Encoding mechanism, for use by XML Protocols that exchange RDF data. This document provides some background material to aid discussion on getting this issue closed.
nearby: soapbuilders work
Some background material.
From the XMLP Issue list...
Description: [email] SOAP/1.1 states that given any data model that can be expressed using the SOAP/1.1 data model consisting of simple types, complex types, and references, it is possible to create an XML schema representing that model. Next, given a particular instance of values (for example a graph) expressed using that XML schema, it is possible to create an XML instance representing those values. This XML instance is what is being transferred within a SOAP message. The recipient of a SOAP message can given the XML schema and the XML instance recreate the original value (for example a graph)
Proposal: The current SOAP/1.1 model seems to be capable of representing directed graphs as well as object graphs and enable a recipient to deserialize an XML instance to recreate those graphs. It is not clear whether there are other data models that potentially are interesting to serialize but not representable within the SOAP data model.
Requirement: The XML Protocol data representation must be able to serialize data based on data models not directly representable by XML Schema simple and complex types. These data models include object graphs and directed labeled graphs. It must be possible to reconstruct the original data from the data representation. Comment: SOAP/1.1 states [6] that given any data model that can be expressed using the SOAP/1.1 data model consisting of simple types, complex types, and references, it is possible to create an XML schema representing that model. Next, given a particular instance of values (for example a graph) expressed using that XML schema, it is possible to create an XML instance representing those values. This XML instance is what is being transferred within a SOAP message. The recipient of a SOAP message can given the XML schema and the XML instance recreate the original value (for example a graph).
Judgement: The current SOAP/1.1 model seems to be capable of representing directed graphs as well as object graphs and enable a recipient to deserialize an XML instance to recreate those graphs. It is not clear whether there are other data models that potentially are interesting to serialize but not representable within the SOAP data model.
Henrik: [...] We would like to clarify the relationship between the data model and the particular encoding by saying that the SOAP encoding is one of several potential encodings of the SOAP data model" Danbri: sent pointers to relevant RDF Core WG, specs, asked about test suite work on SOAP Encoding...
Issue 29: "Exist non-serialisable data models?" from [1] implies that there _might_ be data models that cannot be encoded using the SOAP 1.2 data model. When this issue was created I suggested [2] that it was only a true issue if someone could bring forward such a non-serialisable data model. I would like to propose we now close this issue (with no further action) based on the following resolution text: "The current SOAP/1.2 model is capable of representing directed graphs as well as object graphs and enables a recipient to deserialize an XML instance to recreate those graphs. It is not clear whether there are other data models that potentially are interesting to serialize but not representable within the SOAP data model. Since no examples of non-serialisable data models have been brought to the attention of the XML Protocol WG, it is proposed to resolve this issue with no further changes to SOAP 1.2." /paulc [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x29 [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Feb/0045.html Paul Cotton, Microsoft Canada
This is premature!. All the while the SOAP/1.2 spec sports a section "The SOAP Data Model[3] that is yet to be written, you cannot reasonably close this issue by saying "nobody failed to map to our model". Right now, the latest SOAP Working Draft says, under Data Model: "This section is the placeholder for the description of the SOAP data model". The XML Protocol WG charter[4] explicitly calls out (s1.4) two particular information models, RDF and UML. I don't know much about the UML/SOAP relationship, but I've been looking out for opportunities to map RDF into SOAP. You propose to move directly from the current Issue 29 text, "The current SOAP/1.1 model seems to be capable of representing directed graphs as well as object graphs [...]" ...to closure of this issue w.r.t. SOAP 1.2. I suggest we wait until a version of 1.2 has been published that includes a specification of the SOAP Data Model. Currently, the SOAP Data Model is not explicitly articulated, but is described rather indirectly through a rather narrative account of the serialized form given in section 4 of the specification. This makes it hard for other groups reviewing SOAP 1.2 to assess the expressivity of the SOAP data model, or to say with any confidence that SOAP can, or cannot, adequately encode their data model. I appreciate the need to finalise a SOAP 1.2 specification asap, and that there may be other reasons to leave some aspects of the encoding/serialization work to future efforts. Nevertheless, I really don't think the current proposed closure is appropriate at this stage. My particular concern here is the importance of keeping W3C's RDF work alligned with mainstream developments in the XML world, notably SOAP. RDF was, per [3], brought to the attention of the Protocols WG from the start, and makes a fine test case for the closure of Issue 29. I have been looking forward to the day when I can point RDF implementors at a maturing SOAP spec and say "here's the SOAP data model; here's a suite of SOAP test cases; do these map to/from RDF?". I don't believe we're at that stage yet, and that consequently it is too early to say that ..."no examples of non-serialisable data models have been brought to the attention of the XML Protocol WG". The RDF community has been living with a W3C REC (the '99 RDF Model and Syntax spec) that did not adequately distinguish between an abstract information model and its particular default XML encoding. For RDF, this caused significant problems for users of the spec, which we are now addressing through a reformulation of the RDF syntax spec[5], through a more formal and mathematical account of our underlying model[6], and through a set of test cases that guide our discussions[7]. My understanding is that the SOAP 1.2 spec is taking a similar turn: a re-articulation of the SOAP Data Model, (also too the account of serialization rules?), and I believe working towards a SOAP test suite? If so, these efforts have more in common with the RDF Work than some might have expected. I didn't mean to write such a long note, just really wanted to pop up and say "please don't close this issue before publishing a description of the SOAP data model". When that's done, I will take care (via the W3C XML and S.W. CGs) to make sure the spec gets a careful review from the RDF community, particularly regarding the ability to round-trip RDF data graphs through a SOAP representation. danbri [3] http://www.w3.org/TR/soap12-part2/#datamodel [4] http://www.w3.org/2000/09/XML-Protocol-Charter#scope [5] http://www.w3.org/TR/rdf-syntax-grammar/ [6] http://www.w3.org/TR/rdf-mt/ [7] http://www.w3.org/TR/rdf-testcases/
Re: RSVP: Resolution to issue #29 satisfactory? (fwd), Jacek Kopecky, Thu, Nov 01 2001
can you please elaborate on why using SOAP Data Model and SOAP Encoding is the preferred way for you? In my opinion if a SOAP message is to carry RDF or XMI data, the data should be present in their "native" form, I don't see a reason for transforming the data to SOAP Data Model. Do you suggest implementations favor the SOAP Encoding? In my experience most implementation allow you to get to the XML of the data and your application must already contain the (de)serialization code anyway so it should be fairly simple to keep that in your new SOAP applications. If mapping the data onto SOAP Data Model the application will either need to be rewritten heavily to work with the new data structures, or they need to do remapping, which must be written from the scratch. In both cases the result is costly, while using your native XML encoding should bring little cost when you make SOAP applications. Do I have some of my underlying assumptions wrong? I haven't worked much with RDF or XMI.
we shouldn't be casual about creating further divisions between W3C XML languages: if RDF maps into the SOAP-encoding model, we gain a common approach to structured data exchange in the Web. If it doesn't, that's a shame, life goes on. But I want to hear a clear account of what SOAP-encoding is *for* if I'm to adopt the view that RDF (and XMI) apps shouldn't expect to use it. If RDF and XMI developers shouldn't expect to find any use in the SOAP-encoding mechanism, who should? Topicmaps folk? semi-structured database developers?[...] At this stage in SOAP's development (ie. when the Data Model bit of the spec isn't completed) I believe it premature to say "RDF is a different, alien data format; we'll carry it through in its own syntax".
It may well be that RDF is significantly and interestingly different from the SOAP-encoding data model. In that case, using RDF's native XML encoding makes sense. But if the models are close, and if SOAP tools/applications offer useful services based on the existence of the SOAP data model and encoding syntax, we should think carefully before saying that this part of SOAP is useless to a whole family of W3C work. My hope is that, as the SOAP Test Suite work (re encoding) matures and the Data Model section of the spec becomes more explicit, we'll gain a clearer understanding of how SOAP-encoding relates to this other area of W3C work. Until we get to that stage, it seems premature to say "SOAP-encoding was designed to support the exchange of semi-structured XML graph data; except for RDF and XMI and ... (topic maps too?), for which SOAP apps should exchange using the native encodings for those formats". This to my mind undercuts the value of having a SOAP-encoding specified at all. It focusses attention on the need for the spec to say more clearly when we should expect XML-protocol based web services to adopt the SOAP encoding and data model. Short version: "what is SOAP-encoding for? what is it *not* for?"Next steps...?
Where do we go from here?
questions...
What problem is SOAP Encoding trying to solve? From early experience and working from the unfinished 1.2 specification, it appears that the abstract RDF edge-labeled graph may be very similar to the SOAP Encoding Data Model. SOAP 1.2 certainly allows us to send RDF in its native XML encoding, and provides constructs that label this so that SOAP 1.2 tools know that a different from the default data Encoding convention is being used. While this is useful, it is not yet enough. There are two distinct options for shipping RDF around using SOAP: we either use Encoding or we don't. If we don't, is this a problem? Will this create a division between two large families of Web application, namely Web Services (built on SOAP) and the Semantic Web (built on RDF)? This motivates some caution w.r.t. including an RDF-like graph exchange formalism as an adjunct to the main XML Protocol aspect of the SOAP 1.2 specification.
The SOAP 1.2 specification does not provide adequate guidance to implementors as to when use of Encoding is appropriate, except to note that it has been found a useful convention amongst the RPC programming community. As a W3C Recommendation-track specification, we need SOAP 1.2 to provide a better account both of the technicalities (an explicit specification of the SOAP Encoding Data Model) and the motiviation: what is this proposed technology for? For RPC only? For loosly coupled systems? For use instead of adopting a specific Schema/DTD?
Next...? Can we create a better Issue to capture this situation, and close #29? Can we find owners for the actions drafted above?
Dan Brickley, danbri@w3.org 2001-11-07