Votes
ContainerNode
From the introduction above :
this cannot hold any data (no bytes) but can have .... views for container level formatting (aggregate zip/gzip)
So, we have :
- A ContainerNode may have child nodes
- A ContainerNode cannot hold any data
- A ContainerNode may have a list of views for accessing aggregated data.
The 'no data' part is (backend) storage specific, and should not be part of the external interface
The specification should define what an external actor sees, not the internal implementation details.
Note - if it has a list of accepts and provides views, then to an external Actor a ContainerNode behaves the same way as a DataNode,
and does indeed appear to handle data.
So the definition becomes :
- A ContainerNode may have child nodes
- A ContainerNode may have a list of views for accessing aggregated data.
However, I don't see the need to specify what type of data the views may or may not provide.
A view that provided additional DublinCore metadata about the container itself is perfectly valid, but would be excluded by the 'aggregated data' clause.
So the definition simply becomes :
- A ContainerNode may have child nodes
- A ContainerNode may have a list of views.
Votes
Separation of views and formats
I think it may be useful to re-visit how we represent views and data formats.
In the current schema, we attempt to combine the two concepts in one view URI.
We can either represent what the object is, or we can either represent how the data is formatted.
However, I don't think the combined form is capable of representing both concepts clearly enough.
Proposal is that we separate the two concepts, by representing the
data format using a separate XML element and URI.
<node uri="vos://xxxx">
....
<accepts>
<!--+
| This node accepts images.
+-->
<view uri="ivo://vospace/core/view/image">
<!--+
| Formatted as PNG or FITS files.
+-->
<format uri="ivo://vospace/core/format/image-png"/>
<format uri="ivo://vospace/core/format/image-fits"/>
</view>
</accepts>
....
</node>
Votes
Container views
If we registered a view URI that means "access the container as an aggregate" then we would be able to describe views of a container as an archive file.
In this example, the server is saying it can accept a zip or tar archive, and will unpack the
file to create the container contents on the server.
<node uri="vos://xxxx">
....
<accepts>
<!--+
| This (container) node can accept an archive file.
+-->
<view uri="ivo://vospace/core/view/container-archive">
<!--+
| Formatted as a ZIP or TAR file.
+-->
<format uri="ivo://vospace/core/format/archive-zip"/>
<format uri="ivo://vospace/core/format/archive-tar"/>
</view>
</accepts>
....
</node>
In this example, the server can provide a zip or tar archive of the container contents.
<node uri="vos://xxxx">
....
<provides>
<!--+
| This (container) node can provide an archive file of the contents.
+-->
<view uri="ivo://vospace/core/view/container-archive">
<!--+
| Formatted as a ZIP or TAR file.
+-->
<format uri="ivo://vospace/core/format/archive-zip"/>
<format uri="ivo://vospace/core/format/archive-tar"/>
</view>
</provides>
....
</node>
Nested views and formats
If we allow archive formats to contain nested views and formats, then we can specify the type of files within the archive.
In this example, the server can provide a zip or tar archive containing FITS or PNG image files.
<node uri="vos://xxxx">
....
<provides>
<!--+
| This (container) node can provide an archive file of the contents.
+-->
<view uri="ivo://vospace/core/view/container-archive">
<!--+
| Formatted as a ZIP file.
+-->
<format uri="ivo://vospace/core/format/archive-zip">
<!--+
| Containing images.
+-->
<view uri="ivo://vospace/core/view/image">
<!--+
| Formatted as PNG or FITS files.
+-->
<format uri="ivo://vospace/core/format/image-png"/>
<format uri="ivo://vospace/core/format/image-fits"/>
</view>
</format>
</view>
</provides>
....
</node>
Votes
<--
--> |