[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]