RE: [Bug 7586] New: wse:Expires multiple data types creates interop issue

> The spec implies but doesn't state that all data sources MUST support an xs:duration and some data sources MAY additionally support an xs:dateTime

Your reading of MUST and MAY is correct. Let's clarify this in the specification.

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Monday, September 28, 2009 7:56 AM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: Re: [Bug 7586] New: wse:Expires multiple data types creates interop issue

The interop issue doesn't have anything to do with the schema for ExpirationType, it concerns the text in the specification. WS-Enumeration says:
Some data sources might not have a "wall time" clock available, and so are able only to accept durations as expirations. If such a source receives an Enumerate request containing a specific time expiration, then the request MUST fail; if so, the data source SHOULD generate a wsen:UnsupportedExpirationTime fault indicating that an unsupported expiration type was requested.
This leads to the following questions:

  1.  How does a data consumer know whether or not a data source can accept an xs:dateTime? Is it expected to try an xs:dateTime, handle the fault, then try "an equivalent" xs:duration? If so, isn't this rather inefficient?
  2.  The spec implies but doesn't state that all data sources MUST support an xs:duration and some data sources MAY additionally support an xs:dateTime. Given this lack of clarity it seems inevitable that some implementations of the consumer will support only xs:dateTime and be unable to interoperate with sources that support only xs:duration.
There's another issue that affects the use of xs:dateTime that I call the "visibility of expiration inaccuracy issue". Whether it uses xs:duration or xs:dateTime, the consumer can never know exactly when the enumeration will expire because, in the case of xs:duration, it doesn't know when "the clock started ticking" whereas, in the case of xs:dateTime, it doesn't know what differences there may be between its clock and the clock of the data source. However, in the case of xs:duration, the arrival of the wsen:EnumerateResponse message provides some feedback on when the expiration clock started ticking. The consumer knows that the duration began some time after it sent the wsen:Enumerate message and some time before it received the wsen:EnumerateResponse message (we may need to add text to clarify this). Although there could be a large window of time between these two events, the consumer at least knows what the time window is. Such is not the case with xs:dateTime; the clocks of the consumer and the source may disagree by some arbitrary amount and there is nothing in the WS-Enumeration protocol that serves to inform the consumer what that amount might be.

- gp


On 9/27/2009 7:35 AM, Asir Vedamuthu wrote:

To better address the concern quoted in issue 7586, may we request a discussion of the underlying interop issue? What is the interop issue?



For convenience, here is the Expires tag element declaration:



<xs:element name="Expires" type="tns:ExpirationType" .../>



<xs:simpleType name="ExpirationType">

 <xs:union memberTypes="xs:dateTime tns:NonNegativeDurationType" />

</xs:simpleType>



<xs:simpleType name="NonNegativeDurationType">

 <xs:restriction base="xs:duration">

  <xs:minInclusive value="P0Y0M0DT0H0M0S" />

 </xs:restriction>

</xs:simpleType>



Same question applies to issue 7588.



Regards,



Asir S Vedamuthu

Microsoft Corporation



-----Original Message-----

From: public-ws-resource-access-notifications-request@w3.org<mailto:public-ws-resource-access-notifications-request@w3.org> [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org<mailto:bugzilla@wiggum.w3.org>

Sent: Friday, September 11, 2009 5:03 PM

To: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org>

Subject: [Bug 7586] New: wse:Expires multiple data types creates interop issue



http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586



           Summary: wse:Expires multiple data types creates interop issue

           Product: WS-Resource Access

           Version: PR

          Platform: All

        OS/Version: All

            Status: NEW

          Severity: normal

          Priority: P2

         Component: Eventing

        AssignedTo: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org>

        ReportedBy: gilbert.pilz@oracle.com<mailto:gilbert.pilz@oracle.com>

         QAContact: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org>





WS-Eventing allows the Subscriber to use either an xs:duration or an

xs:dateTime for the /wse:Subscribe/wse:Expires value. However, it also allows

Event Sources to fault on the use of xs:dateTime. It hints, but doesn't

directly say, that all Event Sources MUST support xs:duration, but some Event

Sources MAY also support xs:dateTime.



Note: a proposal for this already exists in the proposal for 7478. In hindsight

I realize I should have opened this issue first and addressed it separately.