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: Revised Organization to MUWS Primer chapter 2


All,

 

For discussion at the next week’s conf. call (Oct 13).  (NOTE: I had sent an email on this topic last week expecting to discuss on today’s call, but that email had mistake in it, so I’m slightly revising my proposal).

 

My major goal in suggesting a reorganization of chapter 2 is to achieve a more logical progression of the topics, especially the segways to the discussions involving Notifications and Metadata.  (Currently, these topics are used in concrete examples before they are presented in their own sections.)  Also, reorganizing the topics would lead to a more concise, relevant set of examples.  This means eliminating the Language/Translation example in section 2.6 on Adding Ops and Props—sorry, Heather (I think you wrote that example).

 

Here’s how I think Chapter 2 would fulfill my major goal:

 

Sections 2.1 à 2.5 stand as they now are.

 

Section 2.6 is replaced by the current 2.10 on OperationalStatus.  (This is fairly simple material and doesn’t require any of the “special” discussions.)

 

Section 2.7 is replaced by the introduction to the current section 2.9 on Metrics.  This section will cover the CurrentTime property and the metric attributes.  We can use the need to say more about Metrics for the PDA device as a segway to the following topics (e.g., we can create a little scenario that carries through the following sections):

 

Section 2.8 stays the same on Notifications.  (The TopicSpace example uses BatteryCondition related topics.  This example is never fully integrated into the PDA example—e.g., there is no BatteryCondition property, but at this point, I think that is OK.)

 

Section 2.9 is replaced by the current section 2.6 on Adding Ops and Props.  ISSUE: Should a BatteryCondition property be added just to complete the previous example?  The main example, however, should be continuing the development of the Metrics example and add the properties that are currently used in 2.9.2.

 

Section 2.10 is replaced by the current section 2.7 on Extending Capabilities.  The example would be extending the Metrics capability for the ServerConnectionCapability.  (The final paragraphs of the current 2.7, which deal with the metadata aspects of extending a capability, would be cut and handled as part of the next section.

 

Section 2.11 becomes the current 2.13 on Metadata.  The section would complete the Metrics example, using the final paragraphs of 2.7 to complete Metrics example.

 

Section 2.12 becomes the current section 2.11 on State.  (The point of this section is that brings together the whole capability extension mechanism, without interruption.”

 

Section 2.13 becomes the current 2.12 on Relationships

 

Sections 2.14 and 2.15 remain as they now are.

 

If you have thoughts on this reorganization now, I would like to know them and perhaps we won’t need to discuss the reorg next week.

 

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]