Re: [sdd] RE: Groups - New Action Item #0047 2.6.6

[Julia McCarthy <julia@us.ibm.com>]

I believe that customers really do what consistent naming and versioning, even without consideration of automation. They want it so that humans can understand easily the state of their systems. That said, I don't think it is in the scope of the SDD to satisfy this requirement. Rather the SDD should be designed so that future naming and versioning standard(s) created by other standards bodies could be used within the SDD.


Julia McCarthy



"Danielson, Debra J" <Debra.Danielson@ca.com>

"Danielson, Debra J" <Debra.Danielson@ca.com>

03/02/2006 08:06 AM

To	<sdd@lists.oasis-open.org>
cc
Subject	[sdd] RE: Groups - New Action Item #0047 2.6.6

The current wording of 2.6.6 is:

Consistent identity (naming, versioning and describing standard)

The use cases referenced are 197,201 and 205

197	Artifacts	Basic	Consistent naming for artifacts	Customers want update packages with a consistent naming and versioning convention; including drivers, applications and hardware firmware. This consistency is required for automation.	DELL	1.2	duplicate use case	6.6
201	Artifacts	Basic	Standard Package description	Update packages must have a standard package description	DELL	1.3	duplicate use case	6.1 6.6 7.2
205	Management	Basic	Manageability	Update packages shall provide manageability through their meta-data for the payload. It shall contain classification information, hardware applicability information, versioning information and dependencies information.	DELL	3.3	SDD needs to expose all metadata needed to provide IU management; classification metadata as well as requirements (specifically hardware) and versioning;	99.44

I contend that use case 197 has been phrased to suggest a solution – which is using naming and versioning conventions as a way to support automated updates. I suggest that a primary objective of the SDD is to allow automated updates without having to impose restrictions on the naming or versioning of resources. The one piece missing from this requirement is the applicability of the SDD to drivers, applications and hardware firmware – which is covered in 2.5.9, but not referenced as a use case.

2.5.9 The SDD specification must support the ability for the author to define a composition of diverse content including system firmware updates, operating system updates, middleware and application level software.
UC: 150, 197

.
 
For use case 201, the part of the requirement that I agree with is that update packages must have a standard way to provide a description, not that the description should be standardized.  Use case 201 is also referenced in requirement 2.6.1, which I believe addresses this:

2.6.1 The SDD specification must support the ability for the author to define identity information for the solution package which provides a basis for:
1. Asset management – e.g. assisting user registration, identifying the purchased entity, general description of the package.
2. License management – e.g. identifies the licensed entity, information for agreement enforcement.
3. Support/update entitlement and notifications – e.g. determining subscribed updates/refreshes and availability notifications
4. Component reuse during development – e.g. identity to lookup legal, licensing terms
5. Reporting and queries on package repository – e.g. maintenance types, interrogation by 3^rd party tools.
6. Identifying, collecting and integrating the associated documentation - e.g. readmes
The identity information should include at least name, version, applicability and dependencies for packages.
UC: 12, 25, 45, 51, 60, 93, 94, 103, 104, 105, 110, 190, 201

For use case 205, I believe that the salient points are covered in other requirements that reference the use case:

2.6.2 The SDD specification must support the ability for the author to define identity information for the solution and solution components which provides a basis for:
1. Solution lifecycle management – e.g. identifies a meaningful entity to update or uninstall. Information to prepare for installation. Separate component identity and component version.
2. Traceability to build/development environment, e.g. for problem diagnosis. Interaction with common source control system.
3. Traceability to problem management systems e.g. to identify the problems fixed in a new release.
4. License management – e.g. identifies what is actually installed in a component granularity. Registration, auditability, return receipt, a revenue recognition event, a reconciliation event, additional new business event.
5. Correlation into the hosting environment – e.g. native install error logs. Percolation of error information.
6. Component reuse – e.g. capabilities, shielding of developers from internal dependencies of reusable aggregates, shielding of developers from irrelevant information.
7. Reporting and queries – e.g. visibility of subcomponents; maintenance types
8. Maintenance history – e.g. a user viewable record of what maintenance is applied (history file).
UC: 25, 38, 60, 62, 63, 77, 79, 103-109, 110, 124, 135, 137, 167, 172, 205

2.6.3 The SDD specification must support the ability for the author to define information used by a provisioning application or installation program to assist a user in making correct decisions about the selectable variability, including optional features, parameters and targeting decisions. The installation should support both a smooth, easy setup and a setup with sufficient options. It should not require dialogs to a user after the initial set of questions. Useful help messages (tooltips, pop-ups, etc) should be provided. Validation constraints and descriptions/ help for install parameter should be provided.
UC: 1, 2, 41, 88, 110, 205

Regards,
Debra
 
-----Original Message-----
From: julia@us.ibm.com [mailto:julia@us.ibm.com] 
Sent: Wednesday, March 01, 2006 7:03 PM
To: Danielson, Debra J
Subject: Groups - New Action Item #0047 2.6.6
 
 
OASIS Solution Deployment Descriptor (SDD) TC member,
 
Ms. Julia McCarthy has created a new action item.
 
Number: #0047
Description: 2.6.6
Owner: Ms. Debra Danielson
Due: 03 Mar 2006
 
Comments:
Ms. Julia McCarthy  2006-03-02 00:03 GMT
2.6.6  Debra disagrees. We do not want to get into creating naming and versioning standards. Rather the SDD should be able to work with any naming and versioning scheme  with some limitations such as versions that support sequencing. Consistent identity is not the same as naming and versioning. ACTION ITEM #0047  Debra to begin an email chain to determine the intent of this one.
 
View Details:
http://www.oasis-open.org/apps/org/workgroup/sdd/members/action_item.php?action_item_id=1288
 
 
 
PLEASE NOTE:  If the above links do not work for you, your email application may be breaking the link into two pieces.  You may be able to copy and paste the entire link address into the address field of your web browser.
 
- OASIS Open Administration