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

[Keisuke Fukui]

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