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

[Heather Kreger <kreger@us.ibm.com>]

Should we add this to our action items
list?

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>

03/09/2005 07:51 PM

To	"Mitsunori Satomi" <Mitsunori.Satomi@hds.com>, <wsdm@lists.oasis-open.org>
cc
Subject	RE: [wsdm] MOWS Request Processing Digest Notification Act in Interop Scenario.

Well, right. The [mows-events:ManageableEndpoint]
is a relic. I don't
even know how come nobody including myself ever noticed it there before.
That same section contains topics noted with the relic and without the
relic. In any case, this is not a critical issue, as you say since topic
space says it all properly anyways. I would consider this as an errata
for the after-interop time.


-- 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, March 09, 2005 7:09 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
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.
> >
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: wsdm-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsdm-help@lists.oasis-open.org