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: Draft of conformance level spec 1 email


Christine, Randy, and myself have been working out details on
conformance levels (aka compliance levels).  The purpose of
conformance levels is to allow subsets of SDD to be implemented, which
are easier to implement, but still offer features and value and
interoperability that make it worth it to implement the reduced level.

We are striving to minimize the number of defined levels in the spec,
as too many levels is just a waste of time and would not foster
interoperability.  Therefore, we are shooting for 2 levels, but may
end up with 3 (but no more) depending on the feature sets we feel need
to be optional in L1 and/or L2.

This was briefly discussed on Wednesday's conference call, and we
decided to write something up for the group.  What we're trying to do
is first define the levels in terms of the functionality and/or use
cases they support, rather than trying to immediately jump to the part
where schema elements are declared in or out of scope for a particular
level.  To that end, we also decided to at a minimum come out of the
October F2F with all the items pertaining to Conformance level 1 to be
fully specified in the resulting spec.  So, here's what we have for
functionality in L1:


- Objective of level:

Deploy pre-prepared content that needs limited customization (basic
parameters) - descriptor as contract between assembly and operations.

- Required functions:

Solution package with single component (Root SIU/Root SCU) and single
target topology

Defined set of resource types (based on target environment)

Solution package dependency checking for given environment

Updates & fixes

Full rollback on error

Simple uninstall (based on information in single descriptor)

Able to deploy existing artifact formats appropriate for the target

- Does not include:

Selectable Content
Multi-target topology
Undo of updates/fixes
Upgrades that change base resource/solution composition (incl. Obsolescence)
Backwards compatibility, range enforcement
Verification of install, config

The "Does not include" is intended to eliminate most of the complexity
of SDD and make L1 tooling relatively straightforward to implement.


One question I have that I'd like to discuss tomorrow is about
internationalization/localization.  I feel that some limited amount of
i18n/l10n is needed in L1, as at Sun we rarely if ever ship
unlocalized, supported products.


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