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] 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
Tivoli Development
Deployment Engine Design

Inactive hide details for "Danielson, Debra J" <Debra.Danielson@ca.com>"Danielson, Debra J" <Debra.Danielson@ca.com>

          "Danielson, Debra J" <Debra.Danielson@ca.com>

          05/30/2006 04:24 PM





[sdd] Sections 2.1, 2.2, 3.1, 3.2

Comments on the section drafts:


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?


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.


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.


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
VP, Development
Center for Technology Architecture
Tel: +1 908 874 9838
Fax: +1 908 874 3149
Cell: +1 732-331-3383

GIF image

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