- From: Hutchison, Nigel <Nigel.Hutchison@softwareag.com>
- Date: Tue, 16 Oct 2001 18:56:39 +0200
- To: "'Jacek Kopecky'" <jacek@idoox.com>, danbri@w3.org
- Cc: xml-dist-app@w3.org
Jacek, Supposing a Soap message carried a query(say X-Query) to an XML Database and the database sent back a response representing a node set as a serialized XML document. Would all possible responses be encodeable as a SOAP data model? I think not - unless it was a severely crippled XML Database. But it seems like a reasonable requirement. In fact users have asked for it. Does this support your case? Nigel W.O Hutchison Chief Scientist Software AG Uhlandstr 12,D-64297 Darmstadt, Germany +49 6151 92 1207 -----Original Message----- From: Jacek Kopecky [mailto:jacek@idoox.com] Sent: Tuesday, October 16, 2001 6:02 PM To: danbri@w3.org Cc: xml-dist-app@w3.org Subject: Re: Issue 29: Exist non-serialisable data models? Dan, You seem to assume that data passed in SOAP messages must follow the SOAP data model and be encoded using the SOAP encoding rules. Neither is true, please read on. As SOAP (as specified in [3], without the Adjuncts) is a messaging protocol, it can carry any data serialized into XML. From the point of view of the core SOAP, the serialization rules are application-dependent. SOAP provides a mechanism for specifying the encoding rules used for serialization of the data contained in a message - the encodingStyle attribute information item (see [1]). A specified encodingStyle implicitly specifes also the data model. Requirement R402 (and the issue #29 resulting from it) says that SOAP must be able to serialize data in data models not directly representable by XML Schema (which would be a tree data model). It explicitly mentions the object graph data model. SOAP specifies a serialization of one data model, and that would be sections 4 and 3 of Adjuncts [2], so that any data following this data model, which is prevalent e.g. in RPC applications, can be serialized in a common way. I agree the data model section is yet to be written. In case an application's data follows the data model from section 3, it may be serialized using the encoding rules from section 4. In case an application's data (like RDF, for example) doesn't map naturally onto our data model, the application can use its own serialization rules, which can follow some already existing specification. Applications wishing to communicate RDF data only need to agree on a URI that would identify the RDF XML representation, and use that as the encodingStyle attribute information item's value. The serialized form would then follow the already existing RDF XML representation. So I think the right resolution to issue #29 would be: "SOAP specifies how to encode data from the object-graph data model. SOAP also allows the encoding of other data models representable in XML using custom encoding rules identified in the encodingStyla attribute information item in a message. Therefore no data models exist that are serializable to XML but not serializable to SOAP." Jacek Kopecky Idoox http://www.idoox.com/ [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapencattr [2] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/ [3] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/ On Fri, 12 Oct 2001, Dan Brickley wrote: > > Hi Paul, > > > On Thu, 11 Oct 2001, Paul Cotton wrote: > > > 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." > > > 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. > > best wishes, > > 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/ >
Received on Tuesday, 16 October 2001 12:56:52 UTC