Regards,
Debra
From: Julia
McCarthy [mailto:julia@us.ibm.com]
Sent: Thursday, March 02, 2006
11:36 AM
To: Danielson, Debra J
Cc: sdd@lists.oasis-open.org
Subject: Re: [sdd] RE: Groups -
New Action Item #0047 2.6.6
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 3rd 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