Difference between revisions of "Talk:Discovery Change Proposal-3"
(DCP-3 Discussion -- ~~~~) |
|||
| Line 2: | Line 2: | ||
| − | == | + | == The Atom Link Element== |
| + | The goal of DCP-3 is to provide a standardized link definition for relationships between casts and a definition for a cast's relationships to other resources. Each of these link types can be addressed separately. | ||
| + | |||
| + | === Links to form relationships between Casts === | ||
| + | There are four cast types defined: Data, Service, Collection, and Event. Each type serves a unique purpose and requires specific extensions to the base ESIP Atom Response. Linking casts forms a relationship that answers questions like: "Which services are available for this data?" and "Which collections are related to this data?" and "What data is available for this event?" | ||
| + | |||
| + | An Atom link only requires an href. And, since the relationship between casts is between Atom entries, the value of the href must be the entry id, which [http://www.atomenabled.org/developers/syndication/#requiredEntryElements "identifies the entry using a universally unique and permanent URI,"], | ||
| + | |||
| + | The Atom spec very clearly states in the "Extending Atom" section that any fully qualified URI can be used as the value for the "rel" attribute and that . So, the original approach of using an ESIP defined "rel" attribute makes sense. However, the only necessary "rel" values are: | ||
| + | |||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! Link type | ||
| + | ! Description | ||
| + | |- | ||
| + | |http://esipfed.org/ns/discovery/3.0/cast/data# | ||
| + | |Micro-articles of actual data. | ||
| + | |- | ||
| + | |http://esipfed.org/ns/discovery/3.0/cast/collection# | ||
| + | |Micro-articles about collections of data. | ||
| + | |- | ||
| + | |http://esipfed.org/ns/discovery/3.0/cast/service# | ||
| + | |Micro-articles of service definitions. | ||
| + | |- | ||
| + | |http://esipfed.org/ns/discovery/3.0/cast/event# | ||
| + | |Micro-articles of natural phenomenon. | ||
| + | |} | ||
| + | |||
| + | This approach clearly delineates types of casts with minimal extension to the Atom specification. | ||
| + | |||
| + | |||
| + | === Links to external resources === | ||
| + | The IANA rel values are very appropriate for external resources. The DCP-3 "esip:subrel" is not necessary in that context. For example, inside a data cast, a rel value of "enclosure" is well understood to refer to the data itself. The Cast (Atom entry) itself informs an agent about its type (Data, Service, etc.) and repeating that information in the subrel obfuscates the intent of the link. | ||
| + | |||
| + | The esip:serviceProtocol extension is a necessary "evil" to work around non-RESTful and non-describing web services. The value could be changed to "esip:protocol" to cause less confusion. | ||
| + | |||
| + | It is important to note that rel, esip:protocol, and type are optional. | ||
| + | The use of the values within ESIP Atom Responses is by convention. | ||
| + | |||
| + | References: | ||
| + | [http://www.atomenabled.org/developers/syndication/#link Atom link element description] | ||
| + | [http://www.atomenabled.org/developers/syndication/#extensibility Atom extensibility] | ||
Revision as of 10:05, October 25, 2011
DCP-3 Discussion -- Jess Lacy (JessLacy) 09:00, 25 October 2011 (MDT)
The Atom Link Element
The goal of DCP-3 is to provide a standardized link definition for relationships between casts and a definition for a cast's relationships to other resources. Each of these link types can be addressed separately.
Links to form relationships between Casts
There are four cast types defined: Data, Service, Collection, and Event. Each type serves a unique purpose and requires specific extensions to the base ESIP Atom Response. Linking casts forms a relationship that answers questions like: "Which services are available for this data?" and "Which collections are related to this data?" and "What data is available for this event?"
An Atom link only requires an href. And, since the relationship between casts is between Atom entries, the value of the href must be the entry id, which "identifies the entry using a universally unique and permanent URI,",
The Atom spec very clearly states in the "Extending Atom" section that any fully qualified URI can be used as the value for the "rel" attribute and that . So, the original approach of using an ESIP defined "rel" attribute makes sense. However, the only necessary "rel" values are:
| Link type | Description |
|---|---|
| http://esipfed.org/ns/discovery/3.0/cast/data# | Micro-articles of actual data. |
| http://esipfed.org/ns/discovery/3.0/cast/collection# | Micro-articles about collections of data. |
| http://esipfed.org/ns/discovery/3.0/cast/service# | Micro-articles of service definitions. |
| http://esipfed.org/ns/discovery/3.0/cast/event# | Micro-articles of natural phenomenon. |
This approach clearly delineates types of casts with minimal extension to the Atom specification.
Links to external resources
The IANA rel values are very appropriate for external resources. The DCP-3 "esip:subrel" is not necessary in that context. For example, inside a data cast, a rel value of "enclosure" is well understood to refer to the data itself. The Cast (Atom entry) itself informs an agent about its type (Data, Service, etc.) and repeating that information in the subrel obfuscates the intent of the link.
The esip:serviceProtocol extension is a necessary "evil" to work around non-RESTful and non-describing web services. The value could be changed to "esip:protocol" to cause less confusion.
It is important to note that rel, esip:protocol, and type are optional. The use of the values within ESIP Atom Responses is by convention.
References: Atom link element description Atom extensibility
