- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 14 Apr 2000 14:43:22 -0400
- To: Constantine Plotnikov <cap@mail.novosoft.ru>
- Cc: MOREAU Jean-Jacques <moreau@crf.canon.fr>, Dan Connolly <connolly@w3.org>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, David Burdett <david.burdett@commerceone.com>, Ken MacLeod <ken@bitsko.slc.ut.us>, xml-dist-app@w3.org
On Fri, Apr 14, 2000 at 04:17:04PM +0700, Constantine Plotnikov wrote: > Hi! > > 1. Could you please reconsider serialization algorithm? > As for as I understand from your site the SOAP is starting > point for LOPT development. > > We had some problems with implementing soap protocol in java. > The algorithm require two passes for serialization and > deserialization. > > The basic idea I suggest is the same as in java and XMI 1.1 > serialization algorithm. > > When object is serialized, it is assgined id and it is written > as: > <Type id="id0" > > // contents > </Type> > > Later (in the body of the the element or or ), when reference is > encountered, empty element with href is used. > > <List t="i0"> > <Type id="i1" > > <value> > <Element id="i2"> > <parent> > <Type href="i1"/> > </parent> > <Element id="i2"> > </value> > </Type> > <Type id="id0"/> > </List> > > It allow single pass serialization/desirailaization and references > to parent. I do not suggest to use exactly this representation > for protocol. For example XMI 1.1 like optimization for representation > of values may be used. I just want to make (de)serialization simple and > single pass. I'm very interested in building on object model that supports graphs without reading a supporting schema. Let's take a regorous example in C. (I don't use Java because it glosses over the distinction between pointers and nested data.) struct { int i; char c; } t_Foo; struct { char * str; t_Foo * fooPointer; } t_Bar; struct { char * str; t_Foo nestedFoo; } t_Baz; t_Baz myBaz = {"there", {9, 'c'}}; t_Bar myBar = {"hi", &myBaz.nestedFoo}; If we use a something like a hashtable to tell which objects we've serialized, and we are called on to serialize(&myBar, &myBaz), we can write the myBar structure (ignoring SOAP serialization for now): <t_Bar LOTP:name="myBar"> <XMLSchema:string LOTP:name="str">hi</XMLSchema:int> <t_Foo LOTP:type="pointer" LOTP:objectID="t_Foo_0"> <XMLSchema:int LOTP:name="i">9</XMLSchema:int> <XMLSchema:char LOTP:name="c">c</XMLSchema:int> </t_Foo> </t_Bar> <t_Baz LOTP:name="myBaz"> <XMLSchema:string LOTP:name="str">there</XMLSchema:int> <t_Foo LOTP:objectID="t_Foo_0"/> </t_Foo> </t_Bar> I used objectID to make sure it was clear I was identifying the object being generated, not the XML element where it happened to be serialized. This XML element may have another name to make it available to XSLT or something like that. I'll flush this example out with actual XML schema conformance and other tasty tidbits. This example would have been more convient if we were suppposed to serialize(&myBaz, &myBar) as the t_Foo is actually nested in t_Baz, but that wouln't be as rigorous. > 2. Could you please include standard collection types in LOPT namespace. > I think there should be: > Map > List > Bag > > There may be other like Array. Interesting - this is getting to look more and more like RDF. -- -eric (eric@w3.org)
Received on Friday, 14 April 2000 14:45:36 UTC