Re: Infoset based rewrite of SOAP Section 4

Rich,

Would a mixed Infoset/examples spec better match your expectations? e.g.
section 4:

     The document Element Information Item has:
                   A local name of Envelope
                   A namespace name of
     http://schemas.xmlsoap.org/soap/envelope/
                   Zero or more namespace qualified Attribute
     Information Items
                   One or more Element Information Item children in
     order as follows;
                     1.An optional Header Element Information Item as
     described below
                     2.A mandatory Body Element Information Item as
     described below
                     3.Any number of namespace qualified Element
     Information Items with any local name.

     <env:Envelope>
         <env:header>...</>
         <env:body>...</>
         <...>...</>
     </>

Jean-Jacques.



Rich Salz wrote:

> I'm an implementor -- I've done implementations of ports 80, 88, 119,
> and 135 among others. :)  So I don't say this lightly:  rewriting the
> SOAP spec to be based on the Infoset *would be a big loss for
> implementors.*
>
> Network protocols are not built on top of abstract "information unit"
> descriptions. They are best built by from a document that describes both
> bits on the wire -- the syntax -- and the meaning of those bits -- the
> semantics.  An infoset approach loses the first and, for many
> implementors, obscures the second in a layer of abstraction.
>
> If there are parties that must have this information, then make it an
> appendix, possibly normative.
>         /r$
> --
> Zolera Systems, Securing web services (XML, SOAP, Signatures,
> Encryption)
> http://www.zolera.com

Received on Wednesday, 11 July 2001 11:09:05 UTC