RE: [wsdm] MOWS Request Processing Digest Notification Act in Interop Scenario.

[Mitsunori Satomi <Mitsunori.Satomi@hds.com>]

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.
> > 
> > 
>