Comments about the specifications

Dear all,
as I will not be able to attend the meeting today, I'm pasting below my
suggestions for the document with the specifications.
Do you think it would be useful if I contribute with some description of
the implementation/use case at GEOFON?
All the best for the call today!
***********************************************
* Why "Collection state" and subdivide in a 3-tuple? It could be better
to remove this extra level. Does it match the JSON structure? No.
* In JSON it is well organized: “id”, “capabilities” and
“properties” are at the same (top) level. It is clear that “membership”
comes later.
* In the Word document it’s less clear: “id” and “state” at the top
level. Then, “membership”, “capabilities” and “metadata” in a second
level; with “properties” as part of “metadata” in a. 3rd level.
* Naming and organization should be coherent through the different
docs and in the graphic. For instance, the concept “metadata” is present
in the Swagger only once “metadataIsMutable”, so what is exactly
“metadata". There we refer to the “properties”. Probably we should
reduce the number of concepts with a formal meaning in the document to
the ones that are used in the JSON representation of the
Collection/Member. So many subdivisions do not help. In the Swagger page
it’s much clear. I would suggest to go for a description in the document
that goes closer to what we have at the Swagger description.
* "The collection membership is a finite set of collection item
identifiers” Probably replace “set” by “group”; or “set/list”
* In "Trait: Insertions allowed”: both operations can be replaced by
“Insert at (index)”
* In “Trait: Shrinkable”: property “no deletes” would lead to a double
negative expression. If needed, replace by "deletes-allowed” or
something similar. But why not to use the “read-only” property?
* What is exactly "Assemble powercollection : Virtual collection
descriptor”?
* There is no need to be so specific in the names of the roles. In fact,
to my understanding that is completely irrelevant for the operation of
such a system. In any case, a user logs in, tries to do something and is
authorized (or not) by the system. We should not mess up the
specification with the “internal management” of the roles (if any). What
if I want a completely open system with “read-only” collections? I need
no AAI system for that. Any user can create a collection and no one can
delete anything. Even the concept of owner could disappear! (I know it’s
extreme).
* And what if instead of roles I would like to have a user-based ACL (no
roles at all)?
* Again, all this could remain internal and implementation specific. We
have no idea how to send the AuthN information to the system. It could
be SSO, but it could also be digest auth, or a code, etc. A client
trying to use the system needs to know *only* how to identify itself
(out of the scope of this document), and which operations exist to be
executed. If the client cannot execute some method, it will receive a
401 http code and it will be clear for it that there is a problem with
permissions.
* Is there a reason why GEOFON is not in the list of use cases? Probably
I’m confused with the exact meaning of “use case” and “implementation”
in the context of this document?
--
Javier Quinteros
-------------------------------------------
2.4/Seismologie
Tel.: +49 (0)331/288-1931
Fax: +49 (0)331/288-1277
Email: ***@***.***-potsdam.de
___________________________________
Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum GFZ
Stiftung des öff. Rechts Land Brandenburg
Telegrafenberg, 14473 Potsdam