Sections 2.1, 2.2, 3.1, 3.2

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?

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)

Do we need to include a required compliance level in the iudd attributes?

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.

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?

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?

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”.

Re: language_bundle

Comment – use of a different convention here for naming, shouldn’t this be languageBundle?

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?

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?

2.2

Do we expect to recommend a best practice for avoiding name collisions? (ACS recommends one already, correct?)

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?

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.

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.

Sentence needs fixing: “If used, it represents the version the thing identified by the name field.” Missing “of”?

Debra J. Danielson

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

sdd message