Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Doug Bunting wrote:

> The most recent copy of this schema[1] does not seem to support (allow 
> validation of) the WS-Reliability 'bare URI' scheme.  To directly insert 
> text into the wsrm:ReplyTo element, the ref:ServiceRefType type must 
> support mixed content.  That is,
> 
> <xsd:complexType name="ServiceRefType">
>   <xsd:sequence>
>     <xsd:any namespace="##other" processContents="lax"/>
>   </xsd:sequence>
>   <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/>
> </xsd:complexType>
> 
> should instead be
> 
> <xsd:complexType name="ServiceRefType" mixed="true">
>   ...
> </xsd:complexType>
> 
> An alternative would be to leave ServiceRefType as is and define a 
> particular BareURI (simple) type or element in either reference.xsd or 
> ws-reliability-1.1.xsd.  Lots of options but the element would be simple 
> in every case:
> 

Good catch. I too prefer specifying a separate element/type to making it 
mixed. Making it mixed will require us to specify what happens if the 
content is indeed mixed -- i.e. has both CII and EII.
Defining the new element/type for bare URI just seems simpler.

> <xsd:element name="BareURI" type="xsd:anyURI">
> 
> or
> 
> <xsd:simpleType name="BareURIType">
>   <xsd:restriction base="xsd:anyURI" />
> </xsd:simpleType>
> 
> <!--
>    BareURIType would be ref:BareURIType if the element were in the
>    WS-Reliability schema while the type is in the reference schema.
> -->
> <xsd:element name="BareURI" type="BareURIType">
> 
> I lean slightly toward this second approach because it is more 
> consistent with the other expected (WS-Addressing or WS-MessageDelivery, 
> for example) cases.  That is, the element of ref:ServiceRefType would 
> have the consistent semantics of identifying the set of messages in 
> which the contained address is relevant.  The namespace of the contained 
> element and the @reference-scheme value would identify the semantics of 
> that address.
> 
> Which raises another niggle I had not considered earlier: I believe the 
> namespace of the contained element or the direct inclusion of text in 
> the wsrm:ReplyTo element (if we leave that option) provides the same 
> information as the @reference-scheme value.  Do we need both?
> 

The reference-scheme attribute is optional. Therefore if it is 
considered to be redundant for a particular addressing scheme then it 
could certainly not be used (as is the case for bare uri).

Having the optional reference-scheme attribute covers the case where the 
QName of the child EII does not specify the semantics of the addressing 
scheme. For example, WS-MD uses the WSDL 1.1 service element as a 
reference (with some restrictions on the contents of the service 
element). In this case the child EII will be wsdl11:service. It is 
possible that some other spec or some eventual addressing WG/TC may 
decide to use wsdl:service QName but with perhaps slightly different 
semantics/restrictions than WS-MD. In such a case the optional 
reference-scheme attribute comes handy. So I have a slight preference 
for keeping it.

Thoughts?

> thanx,
>     doug
> 
> [1] 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7108/reference-1.1.xsd 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. 
> 
>