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
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens <michael.behrens@r2ad.com> 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...
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 <andre@merzky.net> wrote:
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens <michael.behrens@r2ad.com> 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
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 <andre@merzky.net> wrote:
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens <michael.behrens@r2ad.com> 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" <alan.sill@ttu.edu> 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
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" <ralf@nyren.net> 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 <andre@merzky.net> wrote:
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens <michael.behrens@r2ad.com> 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" <alan.sill@ttu.edu> 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
+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 <andre@merzky.net> wrote:
On Mon, Sep 3, 2012 at 8:35 PM, Michael Behrens <michael.behrens@r2ad.com> 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" <alan.sill@ttu.edu> 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
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<core.pdf>_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
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" <florian.feldhaus@gwdg.de> 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<core.pdf>_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Ralf, Am 25.09.2012 um 10:48 schrieb Ralf Nyren:
On Tue, 25 Sep 2012 08:04:39 +0000, "Feldhaus, Florian"
<florian.feldhaus@gwdg.de> 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<core.pdf>_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
On Tue, 25 Sep 2012 09:05:11 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> 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
Am 25.09.2012 um 11:40 schrieb Ralf Nyren:
On Tue, 25 Sep 2012 09:05:11 +0000, "Feldhaus, Florian"
<florian.feldhaus@gwdg.de> 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
participants (5)
-
Andre Merzky -
Feldhaus, Florian -
Michael Behrens -
Ralf Nyren -
Sill, Alan