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] On Behalf Of bugzilla@wiggum.w3.org
> Sent: Friday, September 11, 2009 5:03 PM
> To: 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
>         ReportedBy: gilbert.pilz@oracle.com
>          QAContact: 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.
>
>
>