- From: Andrew Layman <andrewl@microsoft.com>
- Date: Tue, 16 Oct 2001 17:59:52 -0700
- To: <Noah_Mendelsohn@lotus.com>, "Hutchison, Nigel" <Nigel.Hutchison@softwareag.com>
- Cc: <danbri@w3.org>, <jacek@idoox.com>, <xml-dist-app@w3.org>
We are using in a limited way the ID mechanism in section 5. The SOAP encoding rules allow us to convert from a DLG instance plus DLG schema to XML syntax plus XML schema; they also allow the reverse translation. The reference to ID indicates that in such a produced XML schema, the "id" attribute should be of type ID. However, the conversion from an XML instance to a DLG instance is determined by the DLG schema, not the XML schema. Hence, it is true but not a problem that, as Asir notes, the schema information, if any, that asserts the ID type is not used during XML to DLG conversion. -----Original Message----- From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com] Sent: Tuesday, October 16, 2001 2:03 PM To: Hutchison, Nigel Cc: danbri@w3.org; jacek@idoox.com; xml-dist-app@w3.org Subject: RE: Issue 29: Exist non-serialisable data models? There are limitations on the XML that can be within a SOAP envelope. No PI's, no user-defined entities (no internal subset DTD), and although there have been some very useful points made by Asir that suggest we aren't really using the XML ID mechanism, in practice (because XML only knows about ID types when DTDs are processed, and we don't have 'em) it's probably a mistake to duplicate an ID values between the contents of your data and any ID's used in other header entries. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------ "Hutchison, Nigel" <Nigel.Hutchison@softwareag.com> Sent by: xml-dist-app-request@w3.org 10/16/01 12:56 PM To: "'Jacek Kopecky'" <jacek@idoox.com>, danbri@w3.org cc: xml-dist-app@w3.org, (bcc: Noah Mendelsohn/CAM/Lotus) Subject: RE: Issue 29: Exist non-serialisable data models? 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 21:00:26 UTC