[acs-wg] Archive Descriptors or Resource Propoperties or Both

[Michael Behrens]

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.

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

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

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

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

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

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

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

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?




-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell) *new*
(703) 714-0442 (land)