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)