OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed Reoganization of Chapter 2 of the Primer


All,

 

At the last conf. call I volunteered to verify the consistency of the examples in the Primer.  One of the biggest problems is keeping appendix A in sync with the evolving examples, especially in the light of the recent additions to section 2 regarding notifications (topics) and metadata.  Currently, these documents are developed in several sections and their development is not necessarily consistent. I think a topics document as well as the metadata document should be added to appendix A. 

 

Moreover, chapter 2 is a complicated web of interconnected topics.  There is an organization problem in section 2 in that several subsections refer to the topics and metadata documents before these concepts are explained.  Bryan has a note on p. 26 (in the section 2.7 on Extending Capabilities) referring to this problem and wondering if the discussion of topics should even be mentioned in this section.  (The explanation of topics is not until 2.8.4.)  I think topics should be part of the Extending Capabilities discussion, but currently the organization of the whole chapter is not optimized for the reader.)  In addition, the example given in the sections on Adding Ops and Props and Extending Capabilities exactly parallels the examples given for Metrics: adding a new capability with 2 props, 1 op and an event.  I don’t see why we need two different examples of the same thing.  Since the metrics example is more germane, I would opt for keeping it and dropping the language example.

 

I would like to propose a revised organization of the chapter 2.  (We can discuss this on the next conf. call.  I am currently working on vers 18; I will keep any organizational changes for v. 19.)

 

Section 2.1 à 2.5 as is.  This covers basic WS-RF (RPDoc, WSDL) and WSDM (Identity, ManageabilityCharacteristics) material.

Section 2.6 becomes the current 2.10 Operational State

Section 2.7 becomes the current 2.11 State (this covers extensions to the state model, but that does not require, IMO, the formal mechanisms of extending a capability)

Section 2.8 becomes the introduction section of 2.9 Metrics (just covering the CurrentTime property, which isn’t covered now (!), and the metric attributes).  In a sense, this complete basic MUWS, and we can use that point + the need to say more about Metrics as a segway to the following broader concepts:

 

Section 2.9 becomes the current 2.8 Notifications, which introduces the notion of TopicSpace  (the example in section 2.8.4 is of topics related to BatteryCondition, which I guess is offered only as an example because it is not integrated in the PDA example with respect to any property, etc..  That’s probably OK as a general example.)

Section 2.10 becomes the current 2.6 on Adding Ops and Props.  The examples will be the Metrics prop & op.

Section 2.11 becomes the current 2.7 on Extending Capabilities.  The example here would be extending the Metrics capability for the ServerConnectionCapability.  (This section will include the Topics discussion, but this time for Metrics.  The final paragraphs of the current 2.7, which deals with the metadata aspects of extending a capability, will be cut and handled as part of the next section

Section 2.12 becomes the current 2.13 on Metadata—completing the Metrics example.

 

Section 2.13 becomes the current 2.12 on Relationships

Section 2.14, 2.15 as is.

 

The Metrics discussion gets kind-of spread-out in the text, but I think, in general, the discussions fall into a more logical order—Metrics is kind-of the victim of getting the overall discussion in order because Metrics brings so many of these general topics into play and provides the basis for introducing relevant examples.  Let me know what you think.  (Unfortunately, Bryan is away—without computer or telephone, he tells me.)

Kirk Wilson
Computer Associates

Architect, Development
Office of the CTO
Tele: + 1 802 765-4337
Fax:   + 1 802 765-4339
<mailto:kirk.wilson@ca.com>

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]