Add a standard property for immutable data

[zonia3000]

In the standard properties section it would be useful to add something like the following:

• ivo://ivoa.net/vospace/core#immutable: SHALL be used as the property URI denoting a node that can't be deleted or moved but whose metadata can be edited

Probably in this case there are some properties that should be not modifiable too. I think that groupread and groupwrite properties should be editable to be able to share an immutable node, however length property shouldn't be editable and maybe also mtime (modification time).

[Zarquan]

:+1: I agree this property would be useful.

[Zarquan]

Do we want to say that for a DataNode, immutable means the content cannot be changed.

What does immutable mean for a ContainerNode? Does this mean that the set of child nodes is fixed, and child nodes cannot be added or removed ?

[Zarquan]

For a normal implementation, the length and mtime properties are generated from the content so they would not be editable anyway.

Would it be useful to have a separate category for server generated properties, like length and mtime, which we can add a sentence to explain that these are generated from the content.

[brianmajor]

At CADC we have a non-standard property ivo://cadc.nrc.ca/vospace/core#islocked that we use to lock directories for DOI purposes. Since this is non-standard anyhow changing it to immutable is fine.

It applies to the determination of write/delete permission on a Node of any type.

Having write permission on a Data node means having write permission on that node and read permission on all of its parents.

To be able to add a child node, one needs write permission to the parent Container node and read permission to all parents of that Container node.

[zonia3000]

PR #21 opened for this

[zonia3000]

Would it be useful to have a separate category for server generated properties, like length and mtime, which we can add a sentence to explain that these are generated from the content.

I think that we could split the properties in 2 categories: read only and not read only. This also gives a suggestion about how to populate the readOnly attribute.

There may be some properties (like quota) that are not exactly automatically generated but rather set by an administrator (at least in our implementation), so maybe considering only if they are read only or not is more generic.

[Zarquan]

There may be some properties (like quota) that are not exactly automatically generated but rather set by an administrator

Wouldn't that depend on who is making the request? There could be cases where a property like quota is read-only for most users, but in some implementations it would be modifiable by an administrator.

So for a particular implementation, specific properties, like quota, might be read-only, but the same properties might be read-write by system administrators in other implementations.

On the other hand there are properties like mtime, length and md5sum, which would always be read-only because thay are calculated by the server based on the node content or history.

[Zarquan]

We don't have a lot space in the list of standard properties, so we are limited to how much detail we can fit in. We could put just the outline and then refer to a more detailed section later in the document describing all the details of what an immutable node is and how it behaves.

Splitting this issue into two steps,

1. Define the standard URI for the immutable property (this issue) and PR #21 .
2. Add a new section describing what an immutable node is and how it behaves (new issue).