[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] SOAP 1.2 support in WSRM
Szabolcs, It's better to define 2 different schemas with different targetNamespaces for soap 1.1 and soap 1.2 versions rather than a consolidated one. As per the schema below, here are some comments: 1) <xsd:attribute ref="soap:mustUnderstand" use="optional"/> <xsd:attribute ref="soap12:mustUnderstand" use="optional"/> By having both mustUnderstands 'optional', one can send a RM without any mustUnderstand attribute at all for RM Headers, which is against our specification (our spec. mentions that mustUnderstand attribute must be present). While we can have a complex schema to say that one of them must be present, the problem goes away if we have 2 different schemas. 2) <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" /> <xsd:import namespace="http://www.w3.org/2003/05/soap-envelope" /> Though it should be okay importing the above 2 imports (since the targetNSs are different), it will be better if we avoid it as the local names are same. 3) targetNamespace="http://schemas.fujitsu.com/rm We should start using a standard (OASIS namespace or some other NS) and a valid namespace. -Sunil Szabolcs.Payrits@nokia.com wrote: > Hi, > > I would summarize the minimal changes in the spec needed for SOAP 1.2 support in WSRM: > > - schema must be changed to allow SOAP 1.2 elements to be present in the messages. This means actually SOAP 1.2 MustUnderstand attribute. (see schema below). > > - Fault handling needs to be changed in the spec anyway, because it is not perfectly defined now (breaking SOAP 1.1 rules, no SOAP-level error codes etc..), that's where SOAP 1.2 compatiblity must be cared for. > > - refer to SOAP 1.2 where SOAP 1.1 is referred in the spec. > > You can check the changes between SOAP 1.1 and SOAP 1.2 yourself in Section 6 of the SOAP 1.2 Part 0 (Primer) document. I think all other changes effect the implementation but not the specification. Using Infosets in addition to the schema, may be considered, but is not a must. (However, it means minimal editorial work. For example in Section 3.4.1 there should be a line added: > /rm:ReliableMessage/MessageType > And everything else should remain.) > > Best regards, > Szabolcs > > <?xml version="1.0" encoding="utf-8"?> > <xsd:schema targetNamespace="http://schemas.fujitsu.com/rm" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:ns1="http://schemas.fujitsu.com/rm" > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" /> > <xsd:import namespace="http://www.w3.org/2003/05/soap-envelope" /> > > [...] > > <xsd:element name="MessageHeader"> > <xsd:complexType> > <xsd:sequence> > <xsd:element ref="ns1:From" minOccurs="0"/> > <xsd:element ref="ns1:To" minOccurs="0"/> > <xsd:element ref="ns1:Service" minOccurs="0"/> > <xsd:element ref="ns1:MessageId"/> > <xsd:element ref="ns1:Timestamp"/> > </xsd:sequence> > <xsd:attribute ref="soap:mustUnderstand" use="optional"/> > <xsd:attribute ref="soap12:mustUnderstand" use="optional"/> > </xsd:complexType> > </xsd:element> > > [...] > > <xsd:element name="ReliableMessage"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="MessageType" minOccurs="0"> > <xsd:simpleType> > <xsd:restriction base="xsd:string"> > <xsd:enumeration value="Message"/> > </xsd:restriction> > </xsd:simpleType> > </xsd:element> > <xsd:element ref="ns1:ReplyTo"/> > <xsd:element ref="ns1:TimeToLive" minOccurs="0"/> > <xsd:element ref="ns1:AckRequested" minOccurs="0"/> > <xsd:element ref="ns1:DuplicateElimination" minOccurs="0"/> > </xsd:sequence> > <xsd:attribute ref="soap:mustUnderstand" use="optional"/> > <xsd:attribute ref="soap12:mustUnderstand" use="optional"/> > </xsd:complexType> > </xsd:element> > > [...] > > <xsd:element name="RMResponse"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="MessageType"> > <xsd:simpleType> > <xsd:restriction base="xsd:string"> > <xsd:enumeration value="Acknowledgment" /> > <xsd:enumeration value="Fault" /> > </xsd:restriction> > </xsd:simpleType> > </xsd:element> > <xsd:element ref="ns1:RefToMessageId"/> > </xsd:sequence> > <xsd:attribute ref="soap:mustUnderstand" use="optional"/> > <xsd:attribute ref="soap12:mustUnderstand" use="optional"/> > </xsd:complexType> > </xsd:element> > > [...] > > <xsd:element name="MessageOrder"> > <xsd:complexType> > <xsd:sequence> > <xsd:element ref="ns1:GroupId"/> > <xsd:element ref="ns1:SequenceNumber"/> > </xsd:sequence> > <xsd:attribute ref="soap:mustUnderstand" use="optional"/> > <xsd:attribute ref="soap12:mustUnderstand" use="optional"/> > </xsd:complexType> > </xsd:element> > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]