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: Justifications for "Need work" items in my answer to the survey.


Folks,

I completed survey items through end of 2.5. Since I'm afraid that
I may not be able to address to your potential questions well on the call,
here are justifications for "Need work" items in my answer.

Keisuke Fukui
Fujitsu Limited

General comments: These expression may be consolidated:
   The SDD needs to provide information necessary to support...
   The SDD needs to provide sufficient information to support...
   The SDD must support (optional selection)...
->I believe since the SDD is a document but not an engine providing the capability,
   the third one should read as "must provide information to support ..."
   more appropriately.
   This may be a part of wordsmithing so I selected "Agree" for the relevant
   items.

2.1.1.7 The SDD should provide sufficient information to insure that a
lifecycle operation completes successfully, and that the system is in an
appropriate state.
-> I agree with this. However, the type of information and depth should be
expressed a bit more concretely. What information can insure a lifecycle
operation completes successfully? and for what type of operations? Otherwise,
the item looks like very high level that covers all other requirements.
Alternatively, if we use support instead of insure, it sounds ok to me.

2.1.3 Installation: The SDD must provide the information required install the
contents of a solution package.
-> Typo? I think "... required to install ..." is correct.

2.1.3.3 The SDD must support installation packages which contain
configuration content in addition to install artifacts.
-> It's not clear to me the difference between artifact here and solution in
the next req. I propose not to use the word "artifact". My proposal is "The
SDD must support installation packages which contain configuration content in
addition to what is installed on target environment."

2.1.3.4 The SDD should support the repair of an installed solution.
-> I propose not to use the word "solution". My proposal is "The SDD should
support the repair of an what is installed.

2.1.5.6 Element Update - SDD should permit individual component update,
specifically System Firmware, BIOS, peripheral firmware
-> I'm not sure if the System Firmware, BIOS, peripheral firmware is a
example of component here or more granularity is assumed here. In the latter
case, I think we need SDD definition of component.

2.1.7.1 payload

2.2.2 The SDD MUST be able to specify, as change requirements, software and
other resource instances which must be installed in the environment.
-> I'm not sure what "change requirements" means here. Can we drop the phrase
or reword? Is it a specific format of the description? The same comment
applies toward 2.2.6 and 2.2.8.

2.2.5 The SDD MUST be able to specify, as change requirements, dependencies
between internal components of the solution. For example, SDD MUST be able to
specify where installation of one component is dependent on successful
installation of another component within the solution.
-> I think a degree of granularity means much here. Just saying "between
components" may mean any point of its large spectrum of granularity.

2.2.10 The SDD MUST be able to specify, as update requirements, the
pre-existence of the solution or component instance being updated.
-> I'm not sure what "update requirements" means here. Can we drop the phrase
or reword? Is it a specific format of the description?

2.3.1 The SDD should describe what will be the results of installing the
solution package, to allow a Provisioning Application to determine the
package or set of packages needed to satisfy the requirements for a change
request. In addition, this information should provide the appropriate
information to allow a Provisioning Application to detect that a solution or
components of that solution have already been installed through an
alternative means (“out-of-band” install of existing packages).
-> I hope a requirement and background information in the first sentence
should be described in separate sentences to clarify what is the requirements
for SDD and what is for the tools to use SDD. Same applies to the second one.

2.3.2 The SDD should describe what will be the results of installing the
package to allow for the Solution Integrator to determine the package or set
of packages needed to satisfy the requirements of an application. The
Solution Integrator can integrate the appropriate packages into a single
solution ensuring that the composition is whole.
-> I think the "Solution Integrator" is not well-defined in the context.
In particular, I'm wondering it is a person or a program portion.

2.4.8 The SDD must support installation packages which contain localization
content in addition to install artifacts.
-> Regardless of the description here, SDD should allow any component in any
language as its artifact, as required as in 2.5.6 and 2.5.7. I think what we
need to here is allowing SDD to have relationship with translated language
files that contains human readable text portion in the SDD descriptor itself.
The text for labels, messages, annotations and help/balloon-help for the
user-input specification in SDD is among such case.

2.5.4 The SDD must provide the information necessary to aggregate consumption
requirements and other dependencies and requirements of the Installable
Units, products, and solutions within a composite solution.
-> The phrase "consumption requirements" is not well-defined in this context.
   Does this mean anything else than "the requirements on the target
environments " in 2.2.1?





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