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

----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>; "Noah Mendelsohn"
<noah_mendelsohn@us.ibm.com>
Sent: Friday, March 15, 2002 4:31 PM
Subject: Re: Rework on SOAP 1.2 Part 2: Section 2 and 3


> Gudge, Noah, good work. 8-)
>  I have a few remarks though, some of them may be on stuff that
> was not introduced by your rewrite.
>
>  - 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.

>
>  - 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.


> Before, this was necessary for the so-called "independent"
> elements which went away.

Did they go away with this rewrite or before? ( Just curious. )

>  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.


>
>  - 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?

>
>  - Editorial: Capitalize Encoding where used as the name of the
> encoding present in the SOAP spec.

OK, all instances of 'SOAP encoding' now 'SOAP Encoding'

>
>  - 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.

>
>  - Section 3.1.3 is not from deserialization perspective, while
> 3.1 implies it will be.

I think the individual points are defined in terms of deserialization. The
prose at the begining of 3.1.3 is not, I'll rework it.


>
>  - Old version was IMHO better readable. It flowed. I'll try to
> think about a reorganization of the rewrite to improve this
> aspect (at least as I perceive it).

All suggestions gratefully receieved.


>
>  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.

> Before accepting it though, we have to
> agree that forbidding the so-called "independent element on top
> of serialization" (see my second remark)

OK, so it's this rewrite that forbids independent elements. I'd be happy to
get rid of independent elements but I could go either way

> and the restriction of
> generic compound types (see my third remark)

OK, I guess Asir will have some comments on that.

> is what we want to
> do. I vote yes on all. 8-)

Cool,

Thanks very much for your input

Gudge

Received on Thursday, 21 March 2002 09:32:40 UTC