Re: [ws-dd] Action Item #90: Response to Issues 52 and 56

["Ohtake, Shin" <shin.ohtake@fujixerox.co.jp>]

Toby-san, and everyone,

Thank you for using your important time to consider this issues.
I have a good exprience to think it very deelply,
and get new ideas and view points through the discussion.

I hope the white paper, and it would be good for all DPWS application.

Thanks a lot,
Shin
//

Toby Nixon さんは書きました:
> Dan Driscoll and I were asked by the TC (action item #90) to put 
> together a response to Issues 52 and 56. Here’s a statement that 
> reflects our perspective. We invite comments from others and hope that 
> the TC can reach consensus on this tomorrow.
> 
>  
> 
>             -- Toby
> 
>  
> 
> Concerns are expressed in Issues 52 and 56 regarding the number and 
> frequency of events that may be generated in particular applications of 
> DPWS, such as the WSD-Print and WSD-Scan applications already in use and 
> others that may be defined in the future. In material submitted with 
> Issues 52 and subsequently, Shin Ohtake suggested defining a new event 
> filter dialect based on severity levels, and in Issue 56 Alain Regnier 
> suggested making the XPATH filter defined in WS-Eventing mandatory for 
> all DPWS implementations. We believe that DPWS is not the right place to 
> define either of the proposed solutions. Here’s why.
> 
>  
> 
> Section 1.1 of DPWS says that it should “[c]onstrain Web services 
> protocols and formats so Web services can be implemented on 
> peripheral-class and consumer electronics-class hardware”, and that it 
> should “[d]efine minimum requirements for compliance without 
> constraining richer implementations”. This sets a high bar for what 
> should be mandated in DPWS: mechanisms included in DPWS need to be 
> simple, lightweight, and very broadly applicable across many device 
> classes, while not limiting what can be added to support particular 
> applications.
> 
>  
> 
> WS-Eventing supports a broad range of applications beyond lightweight 
> devices. The XPATH filter defined in WS-Eventing is too 
> resource-intensive to be mandated across all DPWS device classes.
> 
>  
> 
> An event filter based on severity levels could be lightweight, but it’s 
> not broadly applicable across most device classes.
> 
>  
> 
> Any application of DPWS can define event filters specific to that 
> application, such as was done in WSD-Scan. Although a few printer 
> vendors are represented in WS-DD, we don’t have the expertise as a group 
> necessary to make a decision on what event filter would be best for the 
> printing application. Even if we were to add a filter to DPWS now, 
> there’s no guarantee that it would turn out to be the optimal way to 
> solve the problem in WSD-Print. In fact, it would be counterproductive 
> for us to define another filter in DPWS that turns out to not be right 
> for WSD-Print. But since WSD-Print will need to be updated to reference 
> the standardized version of DPWS anyway, the right solution is to bring 
> the experts together and define an appropriate application-specific 
> filter as part of an updated WSD-Print specification.
> 
>  
> 
> A more serious matter is that Issue 52 brings into question the 
> fundamental design of WS-Eventing and the use of TCP and push-model 
> event delivery. Alternative event notification mechanisms such as 
> pull-mode or connectionless notification could be investigated, but this 
> needs more careful study, which is not feasible given the 
> standardization timeline for DPWS 1.1.
> 
>  
> 
> In the TC discussion of these issues, it’s clear that there’s a strong 
> desire to share information and best practices across applications of 
> DPWS. As the industry gains more experience with DPWS, we will want to 
> document the solutions developed so that subsequent efforts don’t have 
> to go through the same trial-and-error as earlier projects. We’ve 
> discussed and committed to forming a DPWS online community to share such 
> information. Rather than update the DPWS specification every time a new 
> event filter is defined for some application, the right solution will be 
> to use this online community to make information available about event 
> filters along with other design elements for DPWS applications. Dan 
> Driscoll has published a paper already that describes additional ways to 
> address the volume and frequency of events; we support posting a more 
> general version of this paper on the community web site rather than 
> incorporating it into DPWS.
> 
>  
> 
> We look forward to working with the DPWS community to address these 
> concerns in the right place and time, but don’t believe that mandating 
> the XPATH filter, defining a severity level filter, or defining 
> alternative event notification mechanisms can be done in the current 
> project to standardize DPWS 1.1.
> 
>  
> 
> Toby Nixon  |  Senior Standards Program Manager  |  Windows Device and 
> Storage Technologies  |  Microsoft Corporation
> 
> toby.nixon@microsoft.com <mailto:toby.nixon@microsoft.com>  |  
> www.microsoft.com <http://www.microsoft.com/> | V: +1 425 706 2792  |  
> M: +1 206 790 6377  |  F: +1 425 708 4811
> 


-- 
------------------------------------------------------------
Shin Ohtake     CTPF-4D, Fuji Xerox Co.,Ltd.
                phone: +81-46-235-6143 (direct)
                mail:  shin.ohtake@fujixerox.co.jp
------------------------------------------------------------