OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] New schema elment/type decl in WSRM schema to includeBareURI


iwasa wrote:

> Anish and Doug,
> 
> I need your help to understand the proposal.
> I think I can understand it if you answer to the
> following questions:
> 
> 1.Are you proposing to add new elements "BareURI"
> as a child element of Request/ReplyPattern/ReplyTo element
> and PollRequest/ReplyTo element ?
> 

The element ReplyTo requires exactly one child element {any}. The 
BareURI element is proposed as the child element of ReplyTo element when 
using the bare URI (default) reference scheme (which is used in our 
examples as well as most implementations).

Please note that BareURI is *not* a required child element of ReplyTo. 
IOW, one could come up with an new addressing scheme or use appropriate 
WS-Addressing, WS-MD element as child element of ReplyTo.

The proposal says what the child element must be when using the bare URI 
scheme.

HTH.

> 2.What is the object for this element?
>    Please review 10. below whether it is correct or not.
> 

Hope my answer to (1) above clarifies this.

> 3.What is the value of this element?
>    -> I believe URI, right?
> 

Technically, its schema type is wsrm:BareURIType which is a restriction 
of xs:anyURI

> And additional questions inline:
> 
> 
>>Tom,
>>
>>Here is a proposal to address the issue raised by Doug [1] regarding the
> 
> use of URI in the addressing container.
> 
>>1) Below is the schema element and type decl that should be added to the
> 
> schema at "ws-reliability-1.1.xsd" --
> 
>><!-- default reference scheme -->
>><xsd:element name="BareURI" type="BareURIType">
>><xsd:simpleType name="BareURIType">
>>  <xsd:restriction base="xsd:anyURI" />
>></xsd:simpleType>
>>
>>
>>Additional changes needed:
>>1) Table 10, section 4.2.3.2 the value for the row 'Child element' is
> 
> incorrect. ReplyTo element requires exactly one EII {any}.
> 
> 4. What is EII? Is EII the name of element?
> 

Sorry, was using the infoset terminology. EII = Element Information 
Item. What I meant to say was that ReplyTo element requires exactly one 
child element. Since the schema has xs:any, the name of the element can 
be anything (subject to the constraints of namespace).

> 5. Are you proposing we change the table 10 as follows?
>     I believe latter.
>             Table 10 ReplyTo element
>         Cardinality        1
>         Value                 String
>         Attributes           reference-scheme
>         Child element    EII (any)
> 
>     Or are you proposing this?
>             Table 10 ReplyTo element
>         Cardinality        1
>         Value                 String
>         Attributes           reference-scheme
>         Child element    BareURI
> 
> 

Value should be 'none' and child element should be '{any}'
BareURI is just one choice. Other child elements are also possible.

>>2) Section 4.2.3.2.1, replace:
>>"The Sending RMP MAY omit this attribute, when the value of the ReplyTo
> 
> element is expressed with a
> 
>>value of type URI."
>>with something like:
>>"The Sending RMP MUST omit this attribute, when the child element of the
> 
> ReplyTo element is wsrm:BareURI"
> 
> 6.Is BareURI the name of new child element of
> Request/ReplyPattern/ReplyTo element and
> PollRequest/ReplyTo element ?
> 

yes.

> 7. What is the relationship between EII and BareURI?
> 

ReplyTo element allows one child element (which is {any}). BareURI is 
the child element of ReplyTo.

> 8. The proposed text is somewhat strange, since it implies
>     the element of ReplyTo can be other than wsrm:BareURI.
>     Do you mean the BareURI is an optional element, and
>     if it is omitted, the Sending RMP MUST omit the reference-scheme
>     attribute?
> 

The child of ReplyTo element is {any} so as to allow composition with 
various existing and future addressing schemes.
WRT omitting the attribute, it is the other way around. The 
reference-scheme attribute must not be used when BareURI is the child 
element of ReplyTo.

If you think that the wording is confusing pl. feel free to change the 
wordings.

> 9. Or does BareURI element mandatory?
> 

No it is not mandatory.
It is used for reference scheme which uses only a URI. One could 
potentially use EPR (WS-Addressing), a wsdl:service element (WS-MD) or 
something else.

> 
>>3) Section 4.3.1, replace:
>>"The format or schema of the value of this element is specified by the
> 
> reference-schema attribute. If the attribute is omitted,
> 
>>the default format of ReplyTo element is URI as defined in [RFC 2396]."
>>with:
>>"The format or scheme of the value of this element is specified by the
> 
> reference-scheme attribute. If the attribute is omitted,
> 
>>the default scheme of ReplyTo element is wsrm:BareURI as defined in
> 
> Section XXXX"
> 
>>4) Add a new section that defines the wsrm:BareURI element consistent with
> 
> definition of other elements in the wsrm schema (editorial). This section
> should also point to Section 6 HTTP binding for an example of how things
> work with a simple URI.
> 
> 10.I have drafted the following text for the new section of BareURI.
> --
> 4.2.3.2.2 Element: Request/ReplyPattern/ReplyTo/BareURI
> The ReplyTo element MUST include this element. This element is

It is not required that ReplyTo element must include BareURI.

> used to specify the endpoint where the initial Sending RMP expects
> to receive a Callback Acknowledgment Indication or RM Fault Indication.
>             Table11 BareURI Element  (*note: This is new table.)
>         Cardinality         1
>         Value                 String

The value is a URI and not a string.

>         Attributes           None
>         Child elements   None
> --
> Are the above sentences right?
> 
> 11. I don't understand what is your expectation for an example
> of simple URI. Could you draft a proposed text?
> 

In the current examples the URI is specified as the content of ReplyTo 
as follows:

...
<ReplyTo>http://someuri</ReplyTo>
...

Instead it should be:

...
<ReplyTo>
   <BareURI>http://someuri</BareURI>
</ReplyTo>
...

> 
>>5) There are a few places where the attribute on the ReplyTo element is
> 
> called 'reference-schema' rather than 'reference-scheme'. A quick search and
> replace should fix this. (Note: this is unrelated to the issue raised by
> Doug)
> 
>>6) Table 15 needs to be modified similar to table 10 in (1) above.
>>
>>7) Section 4.3.1.1 needs to be modified similar to (2) above.
>>
>>8)  Section 6, the following lines need to be changed from:
>>"If a ReplyTo element present in a Request element or Poll Request header
> 
> element, sent using the SOAP 1.1 protocol, contains only a URL and uses the
> 'http:' URL scheme, then the WS-Reliability response MUST be sent using the
> HTTP binding specified in section 6 of SOAP 1.1."
> 
>>to:
>>
>>"If a ReplyTo element present in a Request element or Poll Request header
> 
> element, sent using the SOAP 1.1 protocol, uses the wsrm:BareURI (default)
> reference scheme and uses the 'http:' URL scheme, then the WS-Reliability
> response MUST be sent using the HTTP binding specified in section 6 of SOAP
> 1.1."
> 
>>9) Changes to section 6 should also be made (similar to (8) above) for the
> 
> SOAP 1.2 case..
> 
> 12. Do you like the following text for SOAP1.2 case?
> --
> "If a ReplyTo element present in a Request element or Poll Request header
> element, sent using the SOAP 1.2 protocol, uses the wsrm:BareURI (default)
> reference scheme and uses the 'http:' URL scheme, then the WS-Reliability
> response MUST be sent using the HTTP binding for Request/Response MEP
> specified in SOAP 1.2."
> --
> 

That is exactly what I was thinking of. Thx.

> Thanks,
> 
> Iwasa
> 
> 
>>10) example 12, and example 17 need to be changed to include the 'BareURI'
> 
> element (as a child element of ReplyTo)
> 
>>Hope this addresses the issue raised by Doug.
>>
>>Thx.
>>
>>-Anish
>>--
>>
>>
>>[1] http://www.oasis-open.org/archives/wsrm/200406/msg00176.html
>>
>>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]