RE: Issue 29: Exist non-serialisable data models?

I agree it's not broken.  I think the point is that an XML 1.0 processor 
will not recognize the attrs. as IDs, unless an external DTD or schema is 
supplied (which can't be done in the message).  That might surprise some 
folks, but it's not an error in the spec, I think.  Thanks for the 
clarification.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







"Andrew Layman" <andrewl@microsoft.com>
10/16/01 08:59 PM

 
        To:     <Noah_Mendelsohn@lotus.com>, "Hutchison, Nigel" 
<Nigel.Hutchison@softwareag.com>
        cc:     <danbri@w3.org>, <jacek@idoox.com>, <xml-dist-app@w3.org>
        Subject:        RE: Issue 29: Exist non-serialisable data models?

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:19:33 UTC