Core errata

Ralf Nyren

3 Sep 2012 3 Sep '12

5:01 p.m.

Dear all, I have update the Core document to include the changes discussed on the last few confcalls. The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached. Add a Attribute type to the Core Model -------------------------------------- Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties". Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties. The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before. A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings. Change Action to inherit Category --------------------------------- The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation. An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type. Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers. regards, Ralf

Attachments:

core.pdf (application/octet-stream — 220.1 KB)

Show replies by date

Michael Behrens

3 Sep 3 Sep

6:35 p.m.

Andre Merzky

8:17 p.m.

On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens wrote:

...

Thanks - reading now...looks good. Quick note: Recommend removal of GDF-P-R.183 from header to avoid reader confusion, as the number would change and this is now a draft, right?

Since the changes are normative, the document number will have to change (which means the doc has to go through public review again). Before submitting the document, please make sure that all open 'core' issues are addressed - I don't think it is a good idea to have new spec versions too often. Best, Andre.

...

Also, line 126: change "Attribute describe" to "The Attribute type describes"

Ralf Nyren wrote:

Dear all,

I have update the Core document to include the changes discussed on the last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Nothing is really difficult...

Sill, Alan

4 Sep 4 Sep

10:16 p.m.

See pages 15 and 16 of GFD.152 for guidance as to how and when to use the errata process as opposed to creation of a new document that obsoletes the old one. Note the OGF process is not tuned for publishing small incremental updates, but instead is set up to facilitate production and maintenance of completed standards documents. that having been said, if the changes do not affect conformance, they can often be incorporated in via errata (which should nonetheless be rare and do require agreement among the corresponding authors to request the change). Hope this helps, Alan On Sep 3, 2012, at 3:17 PM, Andre Merzky wrote:

...

On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens wrote:

...
Thanks - reading now...looks good. Quick note: Recommend removal of GDF-P-R.183 from header to avoid reader confusion, as the number would change and this is now a draft, right?

Since the changes are normative, the document number will have to change (which means the doc has to go through public review again).

Before submitting the document, please make sure that all open 'core' issues are addressed - I don't think it is a good idea to have new spec versions too often.

Best, Andre.

...
Also, line 126: change "Attribute describe" to "The Attribute type describes"

Ralf Nyren wrote:

Dear all,

I have update the Core document to include the changes discussed on the last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Nothing is really difficult... _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Ralf Nyren

11 Sep 11 Sep

10:58 a.m.

...

See pages 15 and 16 of GFD.152 for guidance as to how and when to use

...

errata process as opposed to creation of a new document that obsoletes

...

old one.

Note the OGF process is not tuned for publishing small incremental updates, but instead is set up to facilitate production and maintenance of completed standards documents. that having been said, if the changes do not affect conformance, they can often be incorporated in via errata (which should nonetheless be rare and do require agreement among the corresponding authors to request the change).

Hope this helps, Alan

On Sep 3, 2012, at 3:17 PM, Andre Merzky wrote:

...
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens wrote:

...
Thanks - reading now...looks good. Quick note: Recommend removal of GDF-P-R.183 from header to avoid reader confusion, as the number would change and this is now a draft, right?

Since the changes are normative, the document number will have to change (which means the doc has to go through public review again).

Before submitting the document, please make sure that all open 'core' issues are addressed - I don't think it is a good idea to have new spec versions too often.

Best, Andre.

...
Also, line 126: change "Attribute describe" to "The Attribute type describes"

Ralf Nyren wrote:

Dear all,

I have update the Core document to include the changes discussed on

Hi Alan, Thanks for the pointer to GFD.152. Having read the definition I would say the proposed OCCI Core changes falls within Type 1 and 2, i.e. Editorial fixes and Minor technical fixes. What do you others say? I have split up the changes in different commit's so you can view them independently if you like. The reason for pushing these changes is the upcoming JSON rendering (data format). JSON is better at exposing the full potential of the Core model and I believe due to this we found some minor issues with the Core document which needed fixing to have a consistent relationship between the Core and JSON specs. As a bonus the changes makes the existing HTTP Rendering align better with Core as well. Having Action inherit Category is one such example. regards, Ralf On Tue, 4 Sep 2012 22:16:05 +0000, "Sill, Alan" wrote: the the the

...

...
...
last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Nothing is really difficult... _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Sill, Alan

1:24 p.m.

I'll let the rest of the group comment on the technical content issues. Would just like to suggest that you keep your audience in mind - developers and implementers in this case. We just want to keep the right information in front if them. Obviously we do not want too fluid a process, or a spec that changes too often, but I do t think we should be afraid of the document revision/replacement or obsolescence process either. As long as things are kept in a clear, obvious state for imementation, we can do what we want. I'd say there is a clear line in terms of revisions that affect backwards compatibility and conformance. For clarifications, I think we can handle those through simple errata. Again, think of the implementers. We shouldn't be too shy of the new document or public comment process though; it is not too painful. Alan On Sep 11, 2012, at 5:59 AM, "Ralf Nyren" wrote:

...

Hi Alan,

Thanks for the pointer to GFD.152.

Having read the definition I would say the proposed OCCI Core changes falls within Type 1 and 2, i.e. Editorial fixes and Minor technical fixes.

What do you others say?

I have split up the changes in different commit's so you can view them independently if you like.

The reason for pushing these changes is the upcoming JSON rendering (data format). JSON is better at exposing the full potential of the Core model and I believe due to this we found some minor issues with the Core document which needed fixing to have a consistent relationship between the Core and JSON specs.

As a bonus the changes makes the existing HTTP Rendering align better with Core as well. Having Action inherit Category is one such example.

regards, Ralf

...
See pages 15 and 16 of GFD.152 for guidance as to how and when to use

...
errata process as opposed to creation of a new document that obsoletes

...
old one.

Note the OGF process is not tuned for publishing small incremental updates, but instead is set up to facilitate production and maintenance of completed standards documents. that having been said, if the changes do not affect conformance, they can often be incorporated in via errata (which should nonetheless be rare and do require agreement among the corresponding authors to request the change).

Hope this helps, Alan

On Sep 3, 2012, at 3:17 PM, Andre Merzky wrote:

...
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens wrote:

...
Thanks - reading now...looks good. Quick note: Recommend removal of GDF-P-R.183 from header to avoid reader confusion, as the number would change and this is now a draft, right?

Since the changes are normative, the document number will have to change (which means the doc has to go through public review again).

Before submitting the document, please make sure that all open 'core' issues are addressed - I don't think it is a good idea to have new spec versions too often.

Best, Andre.

...
Also, line 126: change "Attribute describe" to "The Attribute type describes"

Ralf Nyren wrote:

Dear all,

I have update the Core document to include the changes discussed on

On Tue, 4 Sep 2012 22:16:05 +0000, "Sill, Alan" wrote: the the the

...
...
...
last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Nothing is really difficult... _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Michael Behrens

13 Sep 13 Sep

2:47 a.m.

+1 Also, please look at the trackers...I added two from past emails which may or may not have been previously captured. The tracker tool can be a helpful - it has worked well for other OGF projects that I've participated in. https://forge.ogf.org/sf/go/projects.occi-wg/tracker.occi_1_1 -- Michael Ralf Nyren wrote:

...

Hi Alan,

Thanks for the pointer to GFD.152.

Having read the definition I would say the proposed OCCI Core changes falls within Type 1 and 2, i.e. Editorial fixes and Minor technical fixes.

What do you others say?

I have split up the changes in different commit's so you can view them independently if you like.

The reason for pushing these changes is the upcoming JSON rendering (data format). JSON is better at exposing the full potential of the Core model and I believe due to this we found some minor issues with the Core document which needed fixing to have a consistent relationship between the Core and JSON specs.

As a bonus the changes makes the existing HTTP Rendering align better with Core as well. Having Action inherit Category is one such example.

regards, Ralf

...
See pages 15 and 16 of GFD.152 for guidance as to how and when to use

...
errata process as opposed to creation of a new document that obsoletes

...
old one.

Note the OGF process is not tuned for publishing small incremental updates, but instead is set up to facilitate production and maintenance of completed standards documents. that having been said, if the changes do not affect conformance, they can often be incorporated in via errata (which should nonetheless be rare and do require agreement among the corresponding authors to request the change).

Hope this helps, Alan

On Sep 3, 2012, at 3:17 PM, Andre Merzky wrote:

...
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens wrote:

...
Thanks - reading now...looks good. Quick note: Recommend removal of GDF-P-R.183 from header to avoid reader confusion, as the number would change and this is now a draft, right? Since the changes are normative, the document number will have to change (which means the doc has to go through public review again).

Before submitting the document, please make sure that all open 'core' issues are addressed - I don't think it is a good idea to have new spec versions too often.

Best, Andre.

...
Also, line 126: change "Attribute describe" to "The Attribute type describes"

Ralf Nyren wrote:

Dear all,

I have update the Core document to include the changes discussed on

On Tue, 4 Sep 2012 22:16:05 +0000, "Sill, Alan" wrote: the the the

...
...
...
last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

-- Nothing is really difficult... _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Feldhaus, Florian

25 Sep 25 Sep

8:04 a.m.

Dear all, Andy and I had a discussion on IDs for OCCI Entities last week wether they should be UUIDs and wether they have to be globally unique. In the published version of OCCI Core, it states that entity IDs must be URIs and "A unique identifier (within the service provider’s name- space) of the Entity sub-type instance.". In 3.1 of the OCCI RESTful HTTP Rendering document, it says: "Each resource instance within an OCCI system MUST have a unique identifier stored in the occi.core.id attribute of the Entity type [1]. It is RECOMMENDED to use a Uniform Resource Name (URN) as the identifier stored in occi.core.id. The structure of these identifiers is opaque and the system should not assume a static, pre-determined scheme for their structure. For example occi.core.id could be urn:uuid:de7335a7-07e0-4487-9cbd-ed51be7f2ce4." In my opinion it would be very good if both sentences could be moved to OCCI Core to clarify the ID format. Thus we would stress the fact, that UUIDs should be used, but we probably shouldn't require that they have to be used. It is probably not necessary to enforce IDs to be globally unique, but with UUIDs implementers can follow the guidelines in the RFC to ensure global uniqueness. Cheers, Florian Am 03.09.2012 um 19:01 schrieb Ralf Nyren:

...

Dear all,

I have update the Core document to include the changes discussed on the last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Ralf Nyren

8:48 a.m.

...

Dear all,

Andy and I had a discussion on IDs for OCCI Entities last week wether

On Tue, 25 Sep 2012 08:04:39 +0000, "Feldhaus, Florian" wrote: they

...

should be UUIDs and wether they have to be globally unique. In the published version of OCCI Core, it states that entity IDs must be URIs and "A unique identifier (within the service provider’s name- space) of the Entity sub-type instance.". In 3.1 of the OCCI RESTful HTTP Rendering document, it says: "Each resource instance within an OCCI system MUST have a unique identifier stored in the occi.core.id attribute of the Entity type [1]. It is RECOMMENDED to use a Uniform Resource Name (URN) as the identifier stored in occi.core.id.

The structure of these identifiers is opaque and the system should not assume a static, pre-determined scheme for their structure. For example occi.core.id could be urn:uuid:de7335a7-07e0-4487-9cbd-ed51be7f2ce4."

In my opinion it would be very good if both sentences could be moved to OCCI Core to clarify the ID format. Thus we would stress the fact, that UUIDs should be used, but we probably shouldn't require that they have to be used. It is probably not necessary to enforce IDs to be globally unique, but with UUIDs implementers can follow the guidelines in the RFC to ensure global uniqueness.

+1 For the sake of backward compatibility I agree we probably cannot require Entity.ID to be a UUID. A "SHOULD" is an acceptable compromise IMO. Just to clarify, do you think that OCCI Core should recommend a specific format of the Entity IDs as well? I mean, even if Entity.ID is a UUID there are multiple ways to represent a UUID. E.g. canonical form, binary format, URN, etc. Having a specific ID format specified directly in OCCI Core would definitely help with consistency across renderings. However from a technical perspective I think the particular UUID format to use should be up to the rendering. regards, Ralf

...

Am 03.09.2012 um 19:01 schrieb Ralf Nyren:

...
Dear all,

I have update the Core document to include the changes discussed on the last few confcalls.

The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached.

Add a Attribute type to the Core Model --------------------------------------

Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties".

Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties.

The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before.

A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings.

Change Action to inherit Category ---------------------------------

The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation.

An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type.

Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers.

regards, Ralf_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg

Feldhaus, Florian

9:05 a.m.

Hi Ralf, Am 25.09.2012 um 10:48 schrieb Ralf Nyren:

...

On Tue, 25 Sep 2012 08:04:39 +0000, "Feldhaus, Florian"

wrote:

...
Dear all,

Andy and I had a discussion on IDs for OCCI Entities last week wether they should be UUIDs and wether they have to be globally unique. In the published version of OCCI Core, it states that entity IDs must be URIs and "A unique identifier (within the service provider’s name- space) of the Entity sub-type instance.". In 3.1 of the OCCI RESTful HTTP Rendering document, it says: "Each resource instance within an OCCI system MUST have a unique identifier stored in the occi.core.id attribute of the Entity type [1]. It is RECOMMENDED to use a Uniform Resource Name (URN) as the identifier stored in occi.core.id.

The structure of these identifiers is opaque and the system should not assume a static, pre-determined scheme for their structure. For example occi.core.id could be urn:uuid:de7335a7-07e0-4487-9cbd-ed51be7f2ce4."

In my opinion it would be very good if both sentences could be moved to OCCI Core to clarify the ID format. Thus we would stress the fact, that UUIDs should be used, but we probably shouldn't require that they have to be used. It is probably not necessary to enforce IDs to be globally unique, but with UUIDs implementers can follow the guidelines in the RFC to ensure global uniqueness.

+1

For the sake of backward compatibility I agree we probably cannot require Entity.ID to be a UUID. A "SHOULD" is an acceptable compromise IMO.

ok, could you update the OCCI draft then?

...

Just to clarify, do you think that OCCI Core should recommend a specific format of the Entity IDs as well?

I mean, even if Entity.ID is a UUID there are multiple ways to represent a UUID. E.g. canonical form, binary format, URN, etc.

Having a specific ID format specified directly in OCCI Core would definitely help with consistency across renderings. However from a technical perspective I think the particular UUID format to use should be up to the rendering.

Currently the ID format is specified to be the URI format. I wouldn't change that for this revision.

...

regards, Ralf

...
Am 03.09.2012 um 19:01 schrieb Ralf Nyren:

...
...
...
Dear all,

...
...
...
...
I have update the Core document to include the changes discussed on the

...
...
last few confcalls.

...
...
...
...
The LaTeX changes are available from the core-errata branch in the

...
...
occi-wg

...
...
Git repository. Please find a compiled document attached.

...
...
...
...
...
...
Add a Attribute type to the Core Model

...
...
--------------------------------------

...
...
...
...
Many who have implemented the OCCI Core model already added an

Attribute

...
...
type. This change formalise the notion of "attribute properties".

...
...
...
...
Instead of just saying an attribute have a name, an attribute now has

its

...
...
on Attribute type with both name an properties.

...
...
...
...
The new Attribute type is an *identifier* for resource attributes. It

...
...
does

...
...
not contain the attribute value. I.e. just as before.

...
...
...
...
A distinction has been added between "client discoverable attributes"

...
...
(called OCCI Attributes) and attributes internal to the model (called

...
...
model

...
...
attributes). occi.core.id, occi.core.source and occi.core.target have

...
...
been

...
...
changed back to the model attributes they were until shortly before

HTTP

...
...
Rendering was released. These are determined to be model attributes and

...
...
thus receive special care in renderings.

...
...
...
...
...
...
Change Action to inherit Category

...
...
---------------------------------

...
...
...
...
The concept of Action representing the "invocable operation" itself is

...
...
removed. Instead an Action is just an *identifier* of the operation.

...
...
...
...
An Action instance identifies an invocable operation in much the same

...
...
way as a Kind instance identifies an Entity sub-type.

...
...
...
...
Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the

...
...
text/ renderings already use "type=action" in its Category headers.

...
...
...
...
regards, Ralf_______________________________________________

...
...
occi-wg mailing list

...
...
occi-wg@ogf.org

...
...
https://www.ogf.org/mailman/listinfo/occi-wg

Ralf Nyren

9:40 a.m.

On Tue, 25 Sep 2012 09:05:11 +0000, "Feldhaus, Florian" wrote:

...

...
For the sake of backward compatibility I agree we probably cannot

require

...
Entity.ID to be a UUID. A "SHOULD" is an acceptable compromise IMO.

ok, could you update the OCCI draft then?

Sure. I will add that together with the appendix summarizing the errata changes.

...

...
Just to clarify, do you think that OCCI Core should recommend a specific format of the Entity IDs as well?

I mean, even if Entity.ID is a UUID there are multiple ways to represent a UUID. E.g. canonical form, binary format, URN, etc.

Having a specific ID format specified directly in OCCI Core would definitely help with consistency across renderings. However from a technical perspective I think the particular UUID format to use should be up to the rendering.

Currently the ID format is specified to be the URI format. I wouldn't change that for this revision.

So, it would be up to the implementation to decide whether to render Entity.ID as e.g. a URN or an URL with a UUID at the end? (URI = URL | URN) Strictly speaking if Entity.ID is a URI, the following would not be valid right? { ... id: "1b1fcb26-b675-4827-a479-ad77382f51a6" } (taken from the JSON data format examples) It would have to be "urn:uuid:1b1fcb26-b675-4827-a479-ad77382f51a6" instead if I understood the RFC. regards, Ralf

Feldhaus, Florian

9:45 a.m.

Am 25.09.2012 um 11:40 schrieb Ralf Nyren:

...

On Tue, 25 Sep 2012 09:05:11 +0000, "Feldhaus, Florian"

wrote:

...
...
For the sake of backward compatibility I agree we probably cannotrequire Entity.ID to be a UUID. A "SHOULD" is an acceptable compromise IMO.

ok, could you update the OCCI draft then?

Sure. I will add that together with the appendix summarizing the errata changes.

...
...
Just to clarify, do you think that OCCI Core should recommend a specific format of the Entity IDs as well?

I mean, even if Entity.ID is a UUID there are multiple ways to represent a UUID. E.g. canonical form, binary format, URN, etc.

Having a specific ID format specified directly in OCCI Core would definitely help with consistency across renderings. However from a technical perspective I think the particular UUID format to use should be up to the rendering.

Currently the ID format is specified to be the URI format. I wouldn't change that for this revision.

So, it would be up to the implementation to decide whether to render Entity.ID as e.g. a URN or an URL with a UUID at the end? (URI = URL | URN)

Strictly speaking if Entity.ID is a URI, the following would not be valid right?

{

...

id: "1b1fcb26-b675-4827-a479-ad77382f51a6"

}

(taken from the JSON data format examples)

It would have to be "urn:uuid:1b1fcb26-b675-4827-a479-ad77382f51a6" instead if I understood the RFC.

regards, Ralf

You are right, my fault. I will update the examples in the JSON spec. Cheers, Florian

4393

Age (days ago)

4415

Last active (days ago)

List overview

Download

11 comments

5 participants

participants (5)

Andre Merzky
Feldhaus, Florian
Michael Behrens
Ralf Nyren
Sill, Alan

Core errata

Feldhaus, Florian

Feldhaus, Florian

Feldhaus, Florian

tags

participants (5)