Sorry for late reply, comments below:
On Tue, 26 Jun 2012 19:25:31 +0000, "Feldhaus, Florian"
A short summary of the changes / open questions: - should the description of locations and category namespaces go to OCCI Core?
Locations are a pure Http thing and should go into the OCCI HTTP Protocol spec. The Category namespaces are already described in OCCI Core afaik.
- should the Attribute Definition (or whatever we call it) go to OCCI Core?
Yes, I would vote on that.
- how should applicable actions be associated with resources? In text/plain this is done by linking to them. We discussed to include actions as separate entry in resource but didn't specify how. Do we want to do it? Should the resource contain a full rendering of the action? Should we include an association between Resource and Action in OCCI Core?
Good question. We have two cases here: 1. Actions supported by an Entity _class_ 2. Actions applicable to a particular Entity (sub-class) _object_ at a certain point in time. The Kind/Mixin type-system-thingy takes care of case 1. Case 2 would need an association from Entity to Action to express this in Core. Or we could just leave it up to the rendering to offer the information of action applicability as it is right now. I would vote on this. The Action applicability is just a bonus feature, it guarantees nothing. The object state could have change since your last query and the Action you thought applicable would not be so anymore.
- should actions be rendered as part of links? Are there scenarios where an action can be triggered on a link? If so, should we include an association between Link and Action in OCCI Core?
- Do we have to specify an attribute type as used within resource and
Do you mean Actions associated with an OCCI Link? In that case yes. Actions are applicable to Entity and thus to both Resource and Link and any other sub-class. link
in contrast to the attribute definition type?
Not sure what you mean. Currently OCCI HTTP Rendering exposes the type of Entity attributes. This should be supported in JSON as well IMO and need not be changed.
- Should we limit attributes to just strings? Then we don’t need the type property and can use the pattern to define arbitrary restrictions on the content. When using true/false and number as well, we might have trouble with applying the pattern and introduce additional complexity.
See above. We already have fundamental attribute type support in text/plain. Just use the same for JSON. I think we should skip the pattern restriction though. That is where the complexity starts if you ask me. regards, Ralf
Cheers, Florian
Am 26.06.2012 um 18:13 schrieb Feldhaus, Florian:
Hi,
I just updated the OCCI JSON Rendering document in SVN. I also attached the pdf. It includes several points from the discussion during OGF 35. More in the OCCI Call which is taking place right now!
Cheers, Florian
-------------------------------------------------------------------------------
GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de
Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg