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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdd message

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


Subject: Re: [sdd] Some suggested rewrites from the current survey


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would prefer #1.

Jay Nash

Danielson, Debra J wrote:
> Hurrah! 
> 
>  
> 
> Alternative 3:  ?support the author?s ability to define?
> 
>  
> 
> Regards,
> 
> Debra
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Julia McCarthy [mailto:julia@us.ibm.com]
> *Sent:* Thursday, March 02, 2006 8:55 AM
> *To:* Patton, John H
> *Cc:* sdd@lists.oasis-open.org
> *Subject:* Re: [sdd] Some suggested rewrites from the current survey
> 
> Before even getting into the details of these rewrites, I suggest that
> we get rid of the awkward phrasing - "support the ability of the author
> to define". I have a hard time parsing that every time I read it. Here
> are a couple of alternatives.
> 
>    1. "The SDD specification must support definition of"...
>    2. or, if people are really attached to mentioning an author - "The
>       SDD specification must allow the author to define"
> 
> 
> I strongly prefer #1.
> 
> Julia McCarthy
> Autonomic Computing Enablement
> julia@us.ibm.com
> Tie/Line 349/8156
> 877-261-0391
> 
> 
> Inactive hide details for "Patton, John H" <John.Patton@ca.com>"Patton,
> John H" <John.Patton@ca.com>
> 
> *"Patton, John H" <John.Patton@ca.com>*
> 
> 03/01/2006 12:31 PM
> 
> 	
> 
> To
> 
> 	
> 
> 
> <sdd@lists.oasis-open.org>
> 
> cc
> 
> 	
> 
> Subject
> 
> 	
> 
> 
> [sdd] Some suggested rewrites from the current survey
> 
>  
> 
> 	
> 
> 
> These are only suggestions, but I've spent a lot of time trying to think
> of different ways to write a requirement that required little additional
> clarification. I also have some suggestions in the Comments section of
> the survey that are not in this email. Feel free to discuss any of this.
> 
> 
> 2.1.1.6 The SDD specification must support the ability for the author to
> define the requirements that must be met for a provisioning application
> or installation program to rollback or undo a deployment lifecycle
> operation. The SDD specification must support the ability for the author
> to define information needed for a provisioning application or
> installation program to rollback or undo a deployment lifecycle operation.
> 
> 
> 2.1.4.3.1 The SDD specification must support the ability for the author
> to define information about a snapshot configuration.
> 
> 2.1.4.3.2 The SDD specification must support the ability to aggregate a
> snapshot configuration.
> 
> 
> 2.2.11 The SDD specification must support the ability for the author to
> define the information to allow a provisioning application or
> installation program to construct relevant feedback for progress,
> dependency check failures, and change execution failures.
> 
> 
> 2.3 The SDD specification must support the ability for the author to
> define information that describes the changes to the environment after a
> deployment lifecycle operation is complete. The SDD specification must
> support the ability for the author to define requirements that need to
> be met during the integration phase of the deployment lifecycle operation.
> 
> 2.3.1 The SDD specification must support the ability for the author to
> define information that describes the results of installing the solution
> package to allow a provisioning application or installation program to
> determine if the deployment lifecycle operation is needed (if the
> current hosting environment already matches the desired results).
> 
> 
> 2.3.2 The SDD specification must support the ability for the author to
> define information that describes the results of installing the solution
> package to allow the packaging software to determine the package or set
> of packages needed to satisfy the requirements of a solution.
> 
> 
> 2.3.3 The SDD specification must support the ability for the author to
> define the parts of a solution that can be installed as an independent
> subset of the solution.
> 
> 2.3.3.1 The SDD specification must support the ability for the author to
> define information that can be used by a provisioning application or
> installation program to generate a change plan for parts of a solution
> that outlines steps that can be performed manually or by an external
> application.
> 
> 2.3.3.2 The SDD specification must be structured to enable a
> provisioning application or installation program to understand the
> requirements and results of installing individual components of the
> solution, and to identify separately installable, updateable and
> uninstallable parts of a solution.
> 
> 
> 2.4.1.1 The SDD specification must support the ability for the author to
> group user-selectable content at time of deployment. The SDD
> specification must support the ability for the author to define the
> requirements for displaying a group of user-selectable content using
> environmental requirements.
> 
> 
> 2.4.3 Suggestion (2 requirements?): The SDD specification must support
> the ability for the author to 1) specify whether or not multiple
> instances of a solution can be deployed in a single hosting environment,
> and 2) define the parameters needed to allow multiple instances of a
> solution to be deployed in a single hosting environment.
> 
> 
> 2.4.6 Suggestion: The SDD specification must support the ability for the
> author to define packaging metadata that 1) describes the cumulative
> patch levels included in the solution, 2) describes the composition of
> multiple components that are contained in a single artifact, and 3)
> describes how to package a subset of a solution to meet custom
> deployment needs.
> 
> 
> 2.4.7 The SDD specification must support the ability for the author to
> define the information needed by a provisioning application or
> installation program to determine the required initial input needed to
> perform a particular change management operation, and to define the
> information needed to validate that input before proceeding with the
> operation.
> 
> 
> 2.5.2 The SDD specification must support the ability for the author to
> completely define the composition of a solution.
> 
> 2.5.2.1 The SDD specification must support the ability for the author to
> define the exposed features and parameters for the composite solution
> and how these are mapped to the features and parameters of the composed
> components, products, or solutions.
> 
> 2.5.2.2 The SDD specification must support the ability for the author to
> place additional restrictions on the configuration and target of the
> composite solution.
> 
> 2.5.2.3 The SDD specification must support the ability for the author to
> compose a solution that may contribute to meeting the requirements of
> another composed solution.
> 
> 2.5.2.4 The SDD specification must support the ability for the author to
> compose both initial install and maintenance packages into a single package.
> 
> 2.5.2.5 The SDD specification must support the ability for the author to
> specify the disk organization or media layout of a composition.
> 
> 
> ** Some of 2.5.7 feels like it matches composition requirements **
> 2.5.7 The SDD specification must allow solutions to be comprised of a
> single deployment description.
> 
> 2.5.7.1 The SDD specification must allow a solution to contain only
> configuration instructions.
> 
> 2.5.7.2 The SDD specification must allow a solution to contain only
> localization content.
> 
> 2.5.7.3 The SDD specification must allow a solution to contain a single
> maintenance bundle for one or more deployed solutions.
> 
> 2.5.7.4 The SDD specification must allow a solution to contain a single
> bundle of solutions.
> 
> 
> 
> 2.6.2 The SDD specification must support the ability for the author to
> define identity information for the solution to be used in specific
> processes.
> 
> 2.6.2.1 The SDD specification must support the ability for the author to
> define identity information for the solution to be used in solution
> lifecycle management operations.
> 
> 2.6.2.2 The SDD specification must support the ability for the author to
> define identity information for the solution to be used in build and
> development environments.
> 
> 2.6.2.3 The SDD specification must support the ability for the author to
> define identity information for the solution to be used with SCM
> systems. (SCM == Software Configuration Management)
> 
> 2.6.2.4 The SDD specification must support the ability for the author to
> define identity information for the solution to be used with license
> management.
> 
> 2.6.2.5 The SDD specification must support the ability for the author to
> define identity information for the solution to be used with hosting
> environment correlation.
> 
> 2.6.2.6 The SDD specification must support the ability for the author to
> define identity information for the solution to utilize component reuse.
> 
> 2.6.2.7 The SDD specification must support the ability for the author to
> define identity information for the solution to be used in reporting and
> queries.
> 
> 2.6.2.8 The SDD specification must support the ability for the author to
> define identity information for the solution to establish a maintenance
> history.
> 
> 
> 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.
> 
> 2.6.3.1 The SDD specification must support the ability for the author to
> define useful help messages to display in tooltips or message boxes.
> 
> 2.6.3.1 The SDD specification must support the ability for the author to
> define validation constraints, descriptions, and help for install
> parameters.
> 
> 
> 
> 2.7.4 The packaging specification must support the ability for the
> author to define the information in order to enable a provisioning
> application or installation program to verify the integrity or
> authenticity of a package, package content, and package metadata.
> 
> 2.7.4.1 The packaging specification must support the ability to include
> checksums for package contents and a signature for the entire package
> when bundled as a single unit.
> 
> 2.7.6 The SDD specification must support the ability for the author to
> specify file, component, target, and change execution stage requirements
> for lifecycle operations needed by a provisioning application or
> installation program to allow optimization of file distribution.
> 
> 
> 2.8.1 The SDD specification must support the ability for the author to
> compose solutions from existing software packages which do not have an
> SDD. This means the SDD should be able to describe existing software
> packages, including those which:
> 
> 2.8.1.1 The SDD specification must support the ability for the author to
> describe the content variability of an existing software package.
> 
> 2.8.1.2 The SDD specification must support the ability for the author to
> describe the composition of an existing software package.
> 
> 2.8.1.3 The SDD specification must support the ability for the author to
> describe software packages that are deployed using native package
> management.
> 
> 2.13.2 The SDD specification must support the ability for the author to
> view the localized content within a different locale from the target
> platform. The SDD specification must support the ability for the author
> to deploy software that is tied to a different locale from the target
> platform.
> 
> 
> cheers,
> 
> /john patton/
> 
> *--
> ca*
> Senior Software Engineer
> Office: 630 505-6150
> Cell: 847-224-9196_
> _john.patton@ca.com <mailto:john.patton@ca.com>
> 

- --
- --
Jay Nash, CTO
OMS SafeHarbor
128 Warren St
Lowell MA 01852
978.937.2363 ext.111
978.937.3784 fax

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law.  If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on it, is strictly prohibited.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEBvzcHsIa/RmVc78RAuNDAJ0W6jfTBzdDXiPAmqpbXJH/acrBkwCfS6zR
RYziPVK/Ry/5ao4XsMTVfPg=
=/38J
-----END PGP SIGNATURE-----


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