Hi,
I would like to add the following items to the agenda.
Split of Rendering into Protocol & Data Format ---------------------------------------------- Where to describe this separation in the documents? This should go into the rendering document...
OCCI Core? The preamble (include/introduction.tex) included in all documents? ... Agreed. These documents require a description of the specifications and
Great job... Comments in line On 10/2/2012 3:57 AM, Ralf Nyren wrote: the role the specifications in the specification hierarchy.
Pagination ---------- Is the JSON rendering ready for pagination?
If we follow the OpenStack approach to pagination (in the future version of the HTTP rendering doc) almost everything can go into the HTTP request parameters. All good.
However, the ability for a client to distinguish between a full collection response and a partial paginated response is IMO still unresolved.
Adding a "total collection size" item in the JSON response is one solution. Another solution is for the client to ask an extra request to see if there is more data to retrieve.
I don't like the approach taken with openstack for numerous reasons. There is little understanding of query subtleties and the greater issue of query interface and capability.
Action invocation ----------------- Since the JSON payload is designed to be usable with multiple transport protocols I think it is important that you always can determine what a certain JSON payload corresponds to.
How do you distinguish between an Action invocation and a discovery interface response?
If the payload contains an "action" object it is an invocation. If the payload contains an "actions" (plural) it is a discovery response.
So, IMO it works as it is but the difference is indeed subtle.
This goes back to my proposal/discussion to have OCCI data (JSON) as a standalone document, ala OVF. As a stand alone document, occi object life cycle ACTIONs are included in the document. The exact structure and capabilities of a standalone document needs to be defined. A standalone OCCI document can support a more robust semantic for ACTIONs simplifying OCCI administration tasks. A standalone OCCI document can also bring OCCI ACTIONS to less robust protocols, ie. messaging.
Attribute properties -------------------- Have you all looked at the Attribute type in OCCI Core errata? Is everything there now?
I remember Florian talked about an optional "description" property. Should we add that as well? What is the verdict on the core document, a new comment phase or errata ?
regards, Ralf
On Tue, 2 Oct 2012 08:59:46 +0000, "Metsch, ThijsX" <thijsx.metsch@intel.com> wrote:
Hi all,
Important call today on JSON and the OCCI core document! Please join at 4pm UTC, 5pm GMT, 6pm CET.
Numbers:
Austria 0820 4000 1503
Belgium 070 35 99 45
Canada 1 213 289 3444
France 0821 230 748
Germany 01803 001 178
Ireland 0818 270 007
Italy 848 390 166
Netherlands 0870 001 909
Poland 0801 003 533
South Africa 087 550 0375
Spain 902 885 318
Sweden 0939 2066 400
Switzerland 0848 560 190
United Kingdom 0844 4 73 73 73
United States 1 415 363 0833
More: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf
PIN code: 698133
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg