[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] MOWS Request Processing Digest Notification Act in Interop Scenario.
Igor, > -----Original Message----- > From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] > Sent: Thursday, March 03, 2005 8:29 AM > To: Mitsunori Satomi; wsdm@lists.oasis-open.org > Subject: RE: [wsdm] MOWS Request Processing Digest > Notification Act in Interop Scenario. > > Mitsunori, > > That is right it should be "Identity". I'll fix that. > > Regarding the MOWS doc. The mows-events:ManageableEndpoint is > the name of the topic space. We've used that to differentiate > as the WS-Topics spec is not very clear as to what the name > of the topic space should be used for. Those path are only > for documentation purposes, though. They could not be used > when subscribing because one MUST always refer to normative > definition of the topic space at the end of the document and > then pick a dialect to express it when subscribing. I would > remove that prefix in MOWS if we had set for a notation we'd > use for topic paths across the documents. I don't think we > did, actually. I understood that "mows-events:ManageableEndpoint" is the name of topic space. I guess that in MOWS spec., we define the name of topic space as "MOWS" so to use this name ("MOWS") instead of "mows-events:ManageableEndpoint" is another choice to describe topic path. But this is not critical issue. > I noticed that all of the WSDM specifications do not describe > the notation used for notification topics. We do describe all > other notations used in the documents. I've also noticed that > MUWS part 2 document does not have the section describing > notations used in that document. I believe the section should > be there as it must describe the notations used in that > document. It is not reasonable to assume that someone reading > part 2 must always refer to part 1 to understand notational > conventions. I agree with you. > In general I believe we may want to consider the following fixes > (errata?) > - add notational conventions to MUWS part 2 > - add definition of the topic path notation to the > notational conventions section of every document > - explain which topic expression dialect is used in the spec > document itself I think that these modifications or clarifications are better for readers of WSDM spec. But I guess these are not critical issue, so we remind these issues when we write down new version of WSDM specs (or errata of this version). > -- Igor Sedukhin .. (igor.sedukhin@ca.com) > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 Regards, ---- Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com) Director, Advanced Software Architect Hitachi Data Systems Corporation > -----Original Message----- > From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com] > Sent: Friday, February 25, 2005 10:30 PM > To: Sedukhin, Igor S; wsdm@lists.oasis-open.org > Subject: RE: [wsdm] MOWS Request Processing Digest > Notification Act in Interop Scenario. > > Igor, > > As I mentioned at con call, I agreed with your following suggestion. > > And I found the simple (editorial) miss description in > interop scenario. > In "MUWS Identity/Characteristics Act" section, > > > 2. Using the same EPR, retrieve > muws-xs1:ManageabilityCharacteristics > property > > an verify that [MUWS1] Identification capability URI is included > (possibly among others) > > I think "[MUWS1] Identify capability" is correct. > > > And I have a another question about the MOWS specification > document (cd-wsdm-mows-1.0.pdf). > > As the event description of "5.2.6 Request Processing State", > > > 1008 > mows-events:ManageableEndpoint/mows-events:RequestProcessingOb > servations > > I guess "mows-events:ManageableEndpoint/" is not necessary in > this line. > > ---- > Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com) > Director, Advanced Software Architect > Hitachi Data Systems Corporation > > > > -----Original Message----- > > From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] > > Sent: Thursday, February 24, 2005 9:00 AM > > To: Mitsunori Satomi; wsdm@lists.oasis-open.org > > Subject: RE: [wsdm] MOWS Request Processing Digest > Notification Act in > > > Interop Scenario. > > > > You're right, thanks Mitsunori. So there are two ways to fiz this: > > > > 1) Make the subscription to > > mows-events:RequestProcessingObservations and keep the > dialect simple. > > That way ANY notification regarding the request processing will be > > sent. > > This is according to MOWS: > > [ > > mows-events:RequestProcessingObservations indicates availability of > > any information about the processing of any request by the > Web service > > > endpoint (Figure 12) as observed by the implementation of a > manageable > > > Web service. > > ] > > > > 2) Make the dialect a concrete topic expression. > > > > Frankly either way is fine, I believe. 1) may even be simpler. > > > > > > -- Igor Sedukhin .. (igor.sedukhin@ca.com) > > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 > > > > -----Original Message----- > > From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com] > > Sent: Wednesday, February 23, 2005 8:43 PM > > To: wsdm@lists.oasis-open.org > > Subject: [wsdm] MOWS Request Processing Digest Notification Act in > > Interop Scenario. > > > > Hi, Igor and wsdm folks, > > > > I and our engineer in Japan found a little problem in the Interop > > Scenario document (wsdm 1.0 interop scenarios.doc). > > > > In "MOWS Request Processing Digest Notification Act" section, > > > > 2. Using the same EPR subscribe to the > > mows-events:RequestProcessingObservations/Digest > > topic using [BN] Subscribe operation. Indicate the topic and > > [BN] Simple Topic Expression dialect. > > Include an EPR to the receiver of the notification messages > > > > in this case, consumer have to subscribe the child topic of > > mows-events:RequestProcessingObservations. > > But using [BN] SimpleTopic Expression we can subscribe only > the root > > topic as describing in the WS-Topic specification. > > > > ---- wsn-WS-Topics-1.2-draft-01.doc --- > > 343 7.1 SimpleTopic Expressions > > ... > > 357 Because the only valid TopicExpression in this dialect is a > > QName, only root topics can be > > 358 addressed by this grammar. For those entities that > support only > > this dialect of TopicExpression, > > 359 only simple topic spaces, those that define only root topics, > > SHOULD be used. > > --- wsn-WS-Topics-1.2-draft-01.doc --- > > > > I think both are conflicted, so we have to modify the > interop scenario > > > document. > > > > Regards, > > ---- > > Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com) > > Director, Advanced Software Architect > > Hitachi Data Systems Corporation > > > > 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/wsdm/members/leav > > e_workgrou > > p.php. > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]