Defining some asset fields in collections

[matthewhanson]

One of the things we hard originally discussed was having an "available_assets" field. This is a useful field to define in collections, as it tells you what you can expect to find in a single member item.

There's nothing specifically that prevents this from being the case in the definition of collections, but it does make the logic of merging an item with it's collection level metadata more complex. If a collection defines some fields of an asset (the ones that are duplicated across all items such as key, file type, available keys, etc.) and the item defines just the actual URL of those items, then a client that merges them (such as sat-search ) needs to make sure it merges all of the available keys into the correct items.

For example, right now with assets as objects (may change, see #151) in the collection assets could be defined as just a dictionary of keys with empty values:

assets: {
'B1': {},
'B2': {},
'B3': {}
}

Which informs the user who is examining the collection that B1, B2, and B3 are available assets. Otherwise right now, such as in sat-api, you have to look at a specific item to even know what assets are available, and even in that case you are assuming that the one item is representative of all items in the collection, which is a bad assumption. Some items could define additional assets, but the collection should indicate which assets are available in all items.

cc @cholmes @mojodna @scisco

[mojodna]

This still seems achievable using the key or role attribute in place of object keys, indicating which are expected to have values associated.

[matthewhanson]

@mojodna Yes, it is achievable, but only if an id is constrained to be unique among all items in the list. But it also makes it very difficult to merge them as described in #151 whereas a recursive merge of dictionaries is straightforward.

[cholmes]

Moving this to 0.7.0, as getting this in is a top priority for that release, but won't happen here.