Re: Infoset based rewrite of SOAP Section 4

the infoset need add no additional layer to the soap specification. it
stipulates the terms to be used to describe concepts which are already
the subject of the soap specification.

an infoset conform soap specification would offer two concrete
advantages to those implementors who must contend with numerous such
specifications. first all specifications would employ the same terms
where they describe the same things. second, where soap requires
additional entities or properties, or additional relations between
existing entities, these additions can be readily expressed in terms
commensurable with other specifications.

should it turn out that the concepts defined by the infoset are a poor
match to soap's subject, then, yes, one has a problem.

the wording of the opening to the info-set-conform excerpt[1] may be
unfortunate. for example, the phrase "A SOAP message _is_ an InfoSet
..." implies that the infoset is a concrete model. perhaps "_corresponds
to_ an InfoSet" would be better. the infoset spec itself uses "has".
after which the opening phrase would be "A SOAP message has an XML
Infoset which contains at least a <i>Document Information Item</i> with ..."

the subsequent document text did not point up any concept mis-match.



in passing, i note the following:

1. if passages such as the following were rephrased, the text would be
easier to understand:

4.4 SOAP Fault
...

  "The faultcode <i>Element Information Item</i> has;

      A local name of faultcode 
      A namespace name which is empty 

   The type of the <i>Element Information Item</i>"

the preferred phrasing would be:

  "The faultcode <i>Element Information Item</i> has;

      A local name of faultcode 
      A namespace name which is empty 

   The type of the faultcode <i>Item</i>"


sometimes the latter appears, sometimes the former appears. the latter
wording makes it easier to read straight through.



2. i suggest that stipulations be phrased correctly:

4.2.1 Use of Header Attribute Information Items

the sentence

  "A SOAP sender generating an SOAP message SHOULD only use the SOAP Header
   Attribute Information Items on child Element Information Items of the
   SOAP Header Element Information Item."

should be rephrased as

  "A SOAP sender generating an SOAP message SHOULD use the SOAP Header
   Attribute Information Items on child Element Information Items of the
   SOAP Header Element Information Item only."

it would make the specification easier to interpret.


[1] http://marting.develop.com/xmlp/spec_sec4.html


Rich Salz wrote:
> 
> > I think the point
> > some of us are making, and that you might be missing (or may disagree
> > with), is that the infoset can be used to capture what is common across an
> > extensible set of SOAP bindings, each of which must separately meet that
> > goal of concreteness.
> 
> Thanks Noah.
> 
> You're right, I disagree that the infoset is the best approach.  I
> believe it's a bad idea.  In particular, the idea of "describe the
> abstract data" and then "describe particular syntax in detail" scares
> me.  It makes me think of the old 7layer model.  Or describing a stream
> protocol in ASN.1 and then saying "the transfer syntax is DER, and we'll
> call that binding TCP."
> 
> It is possible to do things that way, but it makes it needlessly
> difficult for <emphasize-my-viewpoint>implementors</emph>
>         /r$

Received on Monday, 2 July 2001 13:01:56 UTC