[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]