Hi, I will be able to work on open OCCI topics next week, especially on separating the text rendering from the OCCI API. Anyone interested to move forward here? If so, how should we coordinate the work? Beside that, I collected some comments on the existing / upcoming documents which I'd like to post here for discussion: # HTTP Rendering Category type-identifier - there is a ambiguity in `SCHEME TERM`. As `SCHEME` is defined as being an `URI` it can match `TERM` as well, but `TERM` has a restriction on lowercase. Replace with `SCHEME '#' TERM` . Even better restrict `SCHEME` to URIs without fragment, e.g. `SCHEME AUTHORITY PATH QUERY` (here `SCHEME` means the URI scheme). PATH must be an absolute path, does it? - link-attribute should be the same as attribute-repr - for link definition, the link-type must be put into quotes - unneccessary semicolon at the end of link example - term should be allowed to contain the same characters as the URI fragment to avoid mapping conflicts (e.g. in OpenStack templates can have the same name but different IDs - thus the numeric ID should be used as term, but is currently forbidden. The unrestricted characters of the URI are (per RFC 3986) `ALPHA / DIGIT / "-" / "." / "_" / "~"` and it would be good to use `ALPHA / DIGIT / "-" / "_" / "~"` for term, as the `.` in schemes contains special meaning in OCCI (domain separator). # OCCI Core - where will the definition of OCCI components go. If we have multiple renderings, the definition of e.g. TERM should be the same for all - for mixins, applies should not be automatically inherited from dependent mixins (e.g. a `small` resource template should have `applies` set to the compute kind even though the resource template mixin may have `applies` set to all infrastructure resources # OCCI Infrastructure - in section 3.2.1 add Network kind as related / applies - in section 3.4.1 add the same actions as for Network - clarify templates. If OS templates are only applicable to Compute kinds, they should have the scheme `http://schemas.ogf.org/occi/infrastructurecompute#os_tpl` and related / applies should point to compute - for resource templates, the related / applies should point to all Infrastructure resources (e.g. storage, network, compute, networkinterface, storagelink) # OCCI API Wishlist for the OCCI API document - move all information common to the different renderings into this document or into OCCI Core (e.g. ABNFs) - use query parameters for attribute=value when triggering an action - pagination - as similar to existing REST APIs as possible (e.g. OpenStack, EC2, CIMI) without too many backwards incompatibility with the current HTTP Rendering document Cheers, Florian