W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: What is an independent element

From: Jacek Kopecky <jacek@idoox.com>
Date: Thu, 26 Jul 2001 20:42:04 +0200 (CEST)
To: Murali Janakiraman <murali@roguewave.com>
cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0107262031100.21745-100000@mail.idoox.com>
 Murali, here's how I perceive this.
 I think the section 4 uses the word independent in no special
meaning, while section 5 uses it to mean "at the top level of
serialization".
 This is a somewhat vague specification. I understand it as "on
the same level as the serialization root" and I'm not talking
about the soap-enc:root attribute here.
 In RPC, since the current RPC is modeled as a Struct, this
implicitly constitutes the Body element the top level, so the
independent elements should go into the Body element. On the
other hand if you link from headers to body and back, you might
want to use the common level, and that would be the Envelope.
This might go very well with the trailers because technically
every element in Body is a SOAP block while trailers aren't.

 My feeling is that if the SOAP encoding said "multiref elements
will be trailers" everything would be very much OK. Byt I would
weaken the requirement that every multiref element must be
independent, I'd say "should" because embedding the multiref
elements might in fact ease the processing in some cases.

 Anyway, the old WASP (former IdooXoap) doesn't support SOAP
Encoding multirefs in headers so there's no problem with
multirefs being directly in the Body element.

 Hope it helps, it did help me for thinking about your questions
actually led me to the recollection of trailers and how that
would solve the situation, especially when RPC gets independent
on encodings in SOAP version 1.2.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 24 Jul 2001, Murali Janakiraman wrote:

 >
 >   I am a bit confused with the use of the term "independent element" in the
 > spec. Here are some usage of "independent element" in the spec.
 >
 > *	 Section 5.1, the (first rule) rules for serialization says, "A
 > multi-reference value MUST be represented as the content of an independent
 > element".
 >
 > *	Section 5.1, the terminology section ( bullet 11) says,
 > "Syntactically, an element may be independent or embedded. An independent
 > element is any element appearing at the top level of a serialization.
 >
 > *	Section 4.3.1, says "while both Header and Body are defined as
 > independent elements"
 >
 > *	Section 4.3 says "All immediate child elements of the SOAP Body are
 > called SOAP body blocks and each SOAP body block is encoded as an
 > independent element within the SOAP body. "No" such statement exists for
 > SOAP Header blocks.
 >
 > So, what is an independent element?
 >
 > *	To be an independent element should that be represented as a SOAP
 > Body block.
 > *	Or is an independent element at the same level as SOAP Header and
 > SOAP Body.
 > *	Or the notion of independent element is with respect to usage
 > context, where one could say, this "struct person" is an independent element
 > with in this SOAP Body block.
 >
 > I don't see any issue talking about this. So, I am not sure whether I am the
 > only one confused with this.
 >
 > It seems to me that one possible reason behind the notion of independent
 > element may be to easily locate the "referred" element. If that is the
 > spirit behind it then it makes sense for an independent element to appear at
 > a fixed level.
 >
 > Comments?
 >
 >
 > Murali
 > PS:
 > I also noted this.
 >
 > Section 5.1 , the 6th rule of serialization says, "Strings and byte arrays
 > are represented as multi-reference simple types, but special rules allow
 > them to be represented efficiently for common cases.
 >
 > Does this mean that strings and byte arrays though multi-referred can appear
 > as an embedded element?
 >
Received on Thursday, 26 July 2001 14:42:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT