[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-dd] Action Item #90: Response to Issues 52 and 56
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 ------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]