Re: The reason for roots?

Jacek Kopecky asks (re indep elements):

>> Do we want to reintroduce this complexity?

I think it's harder for deserializers, perhaps easier when serializing an 
arbitrary graph.  Not sure which way I'd prefer to go, but it's not 
clearly a complication in all cases.   One way to write a serializer is 
(a) dump all nodes as independents, with an ID (b) dump all edges as 
hrefs.  We still have to settle the question of "sourceless edges" on the 
indendents, I think, but that's there for the tree root anyway I think (or 
was all this settled in a manner I didn't notice?)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jacek Kopecky <jacek@systinet.com>
Sent by: xml-dist-app-request@w3.org
03/22/2002 10:25 AM

 
        To:     Martin Gudgin <marting@develop.com>
        cc:     XML Protocol Discussion <xml-dist-app@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: The reason for roots?


 Gudge, replies inside. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 22 Mar 2002, Martin Gudgin wrote:

 > ----- Original Message -----
 > From: "Jacek Kopecky" <jacek@systinet.com>
 > Subject: Re: The reason for roots?
 > 
 > >  the problem is that in SOAP 1.1 serialization rules would say
 > > that C must be serialized "as an independent element on top level
 > > of serialization" because it has multiple references to it.
 > 
 > MUST be or MAY be?

In SOAP 1.1, MUST (except for strings and arrays of bytes, I 
think).

 > >  In SOAP 1.2 we haven't forbidden this, although we don't talk
 > > about this any more (so if somebody started from reading SOAP
 > > 1.2, they would not even think of serializing something
 > > out-of-line).
 > 
 > Agreed, although I could add a clause into section 3.1.1 stating how
 > out-of-line serialization would work

Yes, which would reintroduce the explicit statements from SOAP
1.1, maybe lessening the MUST above to MAY. Do we want to
reintroduce this complexity?

 > >  Now if non-roots (non-serialization-roots, that is) can be
 > > anywhere in the message, not just as descendant EIIs of a
 > > serialization root, we have to mark some of them. SOAP 1.1 took
 > > the approach of marking the non-roots that appear somewhere
 > > funky, but this was not crisp enough. So we can either mandate
 > > marking the roots or the non-roots. We chose roots.
 > >  Oh, BTW, I thought my graph below has two roots (according to
 > > your original definition), not zero.
 > 
 > No. It has no root because of rule 2
 > There is no way to get from A to B or B to A. Remember it is a 
*directed*
 > graph.

OK, I understand.

 > Still not convinced we need the notion of root at all in the 
encoding...

If we allow some people to serialize stuff out-of-line, we must 
say where to put these out-of-line non-serialization-roots and 
how to know which is which.

I'm quite OK with the current rewrite's version which disallows 
that out-of-line serialization, thus obviating the root 
attribute. Oh, I think that should go from the rewrite if we 
don't reintroduce the out-of-line serialization.

Received on Tuesday, 26 March 2002 15:30:11 UTC