Hi all,
I believe that we agreed at the last meeting to move
forward with the discussion of these items via email.
Items indicated for group discussion were:
|
|
Item |
Comment |
|
1 |
Normative vs. non-normative text |
Will separate by sections |
|
2 |
Alignment with ACS |
Will do this in the document |
|
3 |
Upward compatible schema versions |
Will not attempt to impose upward compatibility |
|
4 |
Required compliance level |
Comment to be inserted in document as placeholder |
|
5 |
Unique identification of descriptor |
Document why unique identification is useful in
document. Leave optional. |
|
6 |
Value of determining unique identification by matching
key properties or external inputs |
No disposition |
|
7 |
Naming conventions |
No disposition |
|
8 |
Can there be more than one Language bundle for the
descriptor? |
No disposition |
|
9 |
Best practices for avoiding name collisions |
No disposition |
|
10 |
Enumerated values for packageType and contentType –
are there a set of defaults? |
No disposition |
|
11 |
Use of human-readable content by implementations –
must or should use as indicated |
No disposition |
|
12 |
Combine BaseIdentity with Identity? |
Will leave unless someone positively objects. |
So,
Item #6 Does anyone have an example of when it would
be useful to determine the identity of a descriptor by matching key properties
of packageIdentity or external input?
Item #7 I’m surprised that OASIS doesn’t have
a set of conventions? If it doesn’t, then I’d suggest that we
align with the GGF conventions, so that the convergence is as straightforward
as possible.
Item #8 Even though the language bundles may be
really small for the descriptor, I think that it is worthwhile to simple define
a common mechanism for handling multiple language bundles. My experience
is that translations take place very asynchronously, and that trying to fuse,
merge and manage a single bundle can be error prone.
Item #9 I suggest that we leverage the GGF best
practices for avoiding name collisions.
Item #10 I think that it would be useful to predefine
a set of packageTypes (base install, update, upgrade, uninstall, etc)
although I believe we’re all agreed that an implementation wouldn’t
be constrained to them. (Question if we agree to do this, would we
require implementations to support the defined types, or would that be
optional?) I also think that we should predefine a set of common content
types (this is probably easier to do) such as MSI, RPM, ZIP, etc. In this
case, I don’t think that any implementation should be mandated to
implement any content type.
Item #11 I’ve already indicated that I believe
that this ought to be “should” rather than “must”.
(Human readable content should be used as specified).
Regards,
Debra
From: Julia
McCarthy [mailto:julia@us.ibm.com]
Sent: Wednesday, May 31, 2006 2:37
PM
Cc: sdd@lists.oasis-open.org
Subject: Re: [sdd] Sections 2.1,
2.2, 3.1, 3.2
My replies to Debra's comments on the first group of
specification sections are in-line below, in this pen. Many of my replies are simply "group
discussion". These are things I think we need to discuss, at least briefly,
as a group. It would be great if you all looked at this and prepared yourselves
to discuss and resolve these questions tonight. We need to be concise and
efficient since we have a lot to do.
Julia McCarthy
Deployment Engine Design
julia@us.ibm.com
349/8156
877-261-0391
"Danielson,
Debra J" <Debra.Danielson@ca.com>
|
"Danielson,
Debra J" <Debra.Danielson@ca.com> 05/30/2006 04:24 PM |
|
Comments on
the section drafts:
2.1
Question for the TC: Do we
need to distinguish between normative and non-normative text? If so, how?
[djd] – are you
referring to some typeface convention here? Group
discussion topic.
At what point do we
identify the elements that need to align with ACF? Isn’t this one of the
sections that needs to be converged? Should we at a minimum put the alignments
into the document?
Re: schemaVersion
Is there an assumption
that schema versions are upwardly compatible? If no, would there ever be a
situation where you would want to identify 2 schemas? (Note, I don’t
necessarily think that this would be a good idea, but think we should consider
the consequences of a change in schema which would not be upwardly compatible) Group discussion topic.
Do we need to include a
required compliance level in the iudd attributes? Group discussion topic.
Re: descriptorID
Question for the TC: What
does it mean for the creation of compatible implementations to allow this
variability in how descriptors are identified?
What are we identifying
here? It’s just the descriptor itself, right? Not the underlying solution
or any of it’s constituent parts? So I’m not sure that I see the
value of deriving a unique descriptorID from the packageIdentity or external
input. In fact, I think that the uses for the descriptorID are primarily within
the development phase, except that it might be useful for implementations to
know that they have already deployed a specific packaging (not results, which
may be achieved multiple ways) but that this specific construction has already been
applied. I think the descriptorID could also be
very useful when the descriptor needs to be updated in the field without any
change to the overall package. This can happen when there are errors in
dependency checks or when new versions of dependencies become supported due to
further testing. (e.g. A new database product version is tested with the
solution after the solution ships with dependency checks that don't allow that
version.)
In the development phase,
I would think that any tools that construct or edit descriptors would want to
use a unique descriptorID, as the descriptors may be at times without any
related artifacts and/or a packageIdentity that is in flux.
What is the use case for
deriving identity of a descriptor by matching key properties or using external
input? I don't know. Group discussion.
Re: build
Question for the TC: With
all potential unique identifiers defined as optional, it is possible that a
descriptor could have not defined unique identity. That may be fine. Is it?
I’m concerned that
we’re adding a lot of potential complexity here for little or no value.
What’s the benefit of not requiring that a descriptorID / build
combination be unique? Group discussion.
Re the text for the
attribute itself, it’s identified as a non negative integer, but the text
discusses a build date. I think that this section isn’t clear. Change
“build date” to “value in the build attribute”. OK - done.
Re: language_bundle
Comment – use of a
different convention here for naming, shouldn’t this be languageBundle? I agree. Quick group discussion on naming conventions. We may need to
change more than this. For example, some use a convention of capitalizing
element names, but not attributes. Currently, neither element nor attribute
names are capitalized.
What do we do if there are
multiple language bundles? Are we constraining translations to a single bundle?
Isn’t there a requirement to allow the addition of an individual language
to an otherwise complete package? Good
question. Group discussion. But note that the language bundle attribute refers
to the bundle of translations for the descriptor itself. This is not at all
related to language bundles associated with the deployed solution.
Question for the TC:
META_INF directory is defined in the packaging spec. Should the SDD spec refer
to the packaging spec?
Perhaps the data here
should be the languages supported, rather than a path to a bundle? Wouldn't a list of languages have the problem you were objecting to
above - the problem of requiring a change to the original package in order to
support new languages?
2.2
Do we expect to recommend
a best practice for avoiding name collisions? (ACS recommends one already,
correct?) Group discussion.
Re contentType and packageType:
what is the expectation wrt implementations for handling this? Are there any
enumerated values which are inherent to the specification and required by all
implementations? There are no values
inherent to the specification. Group discussion.
3.1
Question for the TC: Must
or Should? Does interoperability require “Must”? Do we intended to
define a schema that support interoperability at this level – i.e. the
level of human readable explanatory information not just deployment declarations?
I think that it is
“should”. The use of the human readable explanatory information is
implementation specific, but the information itself (provided by the developer,
packager or systems integrator) is extremely valuable to the next level in the
food chain, or to the end user by default. Group
discussion.
3.2
Question for the TC: Shall
we combine BaseIdentity with Identity since BaseIdentity is not used anywhere
else?
Why did you compose it
separately in the first place? In general I do not mind having a level of
abstraction that allows for use of BaseIdentity in other constructs while
retaining the ability to extend Identity. It really doesn’t cost anything
except a wee bit of complexity. No discussion needed
unless someone speaks up to argue for combining the two.
Sentence needs fixing:
“If used, it represents the version the thing identified by the name
field.” Missing “of”? Yep.
Fixed. I also changed "thing" to "entity".
Debra
J. Danielson
CA
VP,
Development
Center
for Technology Architecture
Tel:
+1 908 874 9838
Fax:
+1 908 874 3149
Cell:
+1 732-331-3383
Debra.Danielson@ca.com