Re: Rework on SOAP 1.2 Part 2: Section 2 and 3

 Gudge, 
 thanks for the reply, I really appreciate it, considering how 
busy you seem to be right now.
 Please see my replies inline. I've removed the stuff I have no 
reply on (except "yes", "sure" etc.).

                   Jacek Kopecky

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



 > >  - Subsection 2.1.1 should go to section 3, I think, no need to
 > > be this concrete in section 2; same for typing of identifiers or
 > > type names.
 > 
 > I disagree. Section 2 describes the graph. Section 3 describes how to encode
 > the graph in XML.

OK, I think I can go either way after all.

 > >  - Is subsection 2.2.1 needed? It is no longer needed to
 > > distinguish between single reference and multi reference nodes.
 > 
 > I could go either way. I can see leaving it in just so people get the idea
 > that multiple edges may terminate at the same node.

Maybe we could reword the subsection to say that multiple edges 
may terminate at the same node? No need to introduce the single- 
and multi-ref distinction to get the point across.

 > > Before, this was necessary for the so-called "independent"
 > > elements which went away.
 > Did they go away with this rewrite or before? ( Just curious. )

"Independent" elements went away before (when we allowed inline
serialization) because we don't allow (or mandate) them
explicitly any more, but we didn't really forbid them either,
which I think your rewrite does (and I like it), see just below.

 > >  On the other hand, 2.2.1 together with rules in 3.1.1 and the
 > > sentence after the two rules effectively disallow serializing as
 > > "independent" elements, for example
 > >  <foo ref="1"/>
 > >  <blah id="1">42</blah>
 > >  If we go there (and I do like it very much), it needs to be
 > > explicitly mentioned somewhere (possibly the primer) for this is
 > > a significant difference from SOAP 1.1.
 > 
 > I agree that this is a change. I can live with the way it is now. I could
 > also live with having to find a way of describing how to serialize a node
 > out-of-line.

I prefer the way it is in your current rewrite because I don't
know any real need for that, apart from "backwards
compatibility". OTOH, not having to handle "independent" elements
simplifies the writer implementation while leaving the reader
implementation intact.

 > >  - Note that the definition of 'position' restricts generic
 > > compound types: In 2.1.1, position is defined as total order on
 > > all the edges outbound edges of a given node. This removes the B3
 > > compound types from my email [1] and makes generic compound types
 > > almost equivalent to arrays, only the accessor name information
 > > is carried from serialization to the graph.
 > 
 > OK, I'm not sure I understand how edges can be distinguished by position if
 > there is not a total order on edges. Or was this your point about generics
 > in the first place?

If you distinguish by name and position (in this order), it can
be seen as first selecting the children with this name and second
applying the position on this selection. AFAIK, this is what is
usually understood as a multi-struct in programming environments.

 > >  - Why do we have the distinction between locally scoped and
 > > globally scoped identifiers? Especially section 3.1 terminology
 > > is weird since the type of identifier is QName. You have a lot of
 > > text in the rewrite that just makes sure everyone gets the
 > > distinction between locally and globally scoped names, and then
 > > you do nothing with the distinction. 8-)
 > 
 > We do use the distinction in 3.1.3. I guess we Could just say the label is a
 > QName, end of story.

I think we should.

 > >  So the summary would be: I like the way this rewrite moves us
 > > away from XML Schema.
 > 
 > Note that it does this by taking a layered approach. It actually gives us
 > *better* integration with XML Schema because of the appendix describing what
 > happens in that higher layer.

Yes, I understand this, I might have expressed my understanding 
badly though.

 > > and the restriction of
 > > generic compound types (see my third remark)
 > 
 > OK, I guess Asir will have some comments on that.

Oh, AFAIK WebMethods use the generic compound types as they are 
left after your rewrite, so he might actually like this. 8-)

Received on Thursday, 21 March 2002 10:01:06 UTC