Hi Mike, Thanks for your inputs on the resource properties. We will review this in the next meeting. Here are my thoughts. Michael Behrens wrote:

For the draft spec 0.51, I propose these additional optional elements. Perhaps they could be both in the AAD and exposed as resource properties:

<aaf:Requires>xsd:string</aaf:Requires>* The AAID which this one content requires. This can be used to automatically obtain all dependencies.

That's among the possibilities, but I'm hesitant to introduce this into the current specification because of the below reasons: - This introduces the internal dependencies between the AAs in the repository. However, we have not discussed about the net effects or issues involving this. - Generally, the requirements on resource or environment will be described in the standardization such as WS-Agreement, JSDL, DD in SDD and so on and chances are we accommodate them as Application Contents. We should leave the semantical side of these descriptions for the outcome of those on-going activities rather than biting a part of the issues. - Our bottom line choice is to include everything in an AA or including references inside of the AC, leaving the semantical and syntactical details for the prearranged contract between producers and consumers. This helps to keep it clear in what ACS specification defines.

<aaf:Conflicts>xsd:string</aaf:Conflicts>* The AAID which this one conflicts with.

Same as above applies to this.

<aaf:Replaces>xsd:string</aaf:Replaces> The AAID which this one replaces.

I guess this represents exactly the same information as existing AA resource property below: /ari:BaseAA Indicates the endpoint reference of the AA instance which this AA instance is based on, if it is created using Update operation on another AA instance.

<aaf:ReleaseNotes>xsd:string</aaf:ReleaseNotes> (like a readme.txt content)*

There exists a similar element in AAD below: /aaf:AAD/aaf:Descriptions The OPTIONAL element provides human-readable information about the AA. If you intended more lengthy text that cannot fit here, I would propose to include it as a separate Application Contents. Especially, if it is to be interpreted and executed by humane beings, for example, like an installation instruction, it is no use to embed it in a XML document to be parsed by the program and prepared for processing. Also, if there may be multiple files to convey text for humane beings, ACS has no idea how they are presented rather than merely enumerating them on screen without semantics. This can be performed equally using the GetContents over the Application Contents that contains the text.

<aaf:ContentType >xsd:string</aaf:ContentType > The type of content or the purpose of the content: Patch, Base, Differential, Data. Data means non-executable static data.

In the spec, we limit the differential updates in the granularity of application contents. Differential updates in finer granularity than it, for example, using a binary patch is not specified in ACS, though they can be practiced in a implementation specific manner with prior agreement between producers and consumers. If it is true, "patch" is not a candidate at the moment. Base or differential carries the same information as existing AAD or DifferentialAAD element. Data-only AA is ambiguous what it means and how it should be treated by ACS repository.

<aaf:GroupName>xsd:string</aaf:GroupName> This is the group of the AA. This way, a hierarchy can be rendered/determined as needed.

I believe the Name element inside AAID of AAD can act as grouping identifier for some sort, if the producer intended so. I'm curious how the proposed element can serve better than this. I'm open to add more properties, but conservative about adding those that may be redundant or ambiguous about how it should be treated.

<aaf:PatchVersion>asd:string</aaf:PatchVersion>? Indicates the patch number or release if this content is a patch Add to AAID?

If this is about the binary patch version, I think we should suspend to include them until we reach the point when the patch itself is specified in the specification.

<aaf:icon> <small> </small>? <large> </large> </aaf:icon>? This would be a binary PNG 32x32 or 64x64 for use with IDEs, etc.

Interesting. However, it is not clear how it can be utilized. Can we have how those icons should be utilized over the ACS use cases? BTW, in terms of the universal description of the resources, I'm interested in so called Dublin Core metadata information element set, which is a ISO standards. What do you think about this? I'm interested in practices of this on any software or at organizations. ISO 15836:2003(E) Information and documentation -- The Dublin Core metadata element set, 2003-02-26, International Standard <http://www.niso.org/international/SC4/n515.pdf> I was once tempted to refer this in the specification, but I chose to wait to do so until we have concrete use case on these; we have not discussed about how the ACS repository should treat them if included.

ALSO: Installation Package - Mention that an application content (AC) might be stored as an auto-installable format, such as an .msi, or installable/executable jar, or possibly even an .sdd? This would make provisioning/installation (silent installs) easier perhaps. Just an idea for future discussion. I presume we could use SDD equivilants for these and the other ADD elements - if so, perhaps that needs to go into the SDD section that Tom is working.

Multiple Pulls with dependency could be managed using the dependency tree - perhaps using SDD elements?

These should be included in the Open Issues chapter in the specification, since we have not discussed any detail on that. Simple indication of the possibilities without the specific detail cannot be a normative description in the specification in my understanding. All above are my personal opinions. We can review these in the next meeting. I appreciate your inputs very much! -Keisuke