DAP 4.0 Design: Difference between revisions
(New page: == Introduction == Overall Operation == Data Types == == Attributes == == Names == == Services == === Examples === == Responses == Persistent representations === Examples === == ...) |
|||
| Line 3: | Line 3: | ||
Overall Operation | Overall Operation | ||
== | = Data Types = | ||
DAP 4 will have a small increase in supported data types. All of the DAP 2 data types describes in ESE RFC 004.11 will be supported with their existing definition with the exceptions that Grid will be expanded so that it can be used in more situations and strings will comply with UTF-8. The additional types will support 64-bit integers, an Opaque type that can be used for data objects like JPEG images, Groups that can be used to build logical collections as in NetCDF4 or HDF5 (with some limitations over HDF5's definition of Group) and Dimensions. In addition, the server-side of DAP 4 will provide for Type Definitions which will allow data systems that have these to be presented with better fidelity than DAP 2. | |||
== Support for Existing Types == | |||
=== Changes in the Definition of Grid === | |||
=== Changes to the String Type === | |||
== New Datatypes == | |||
=== Opaque === | |||
=== 64-bit Integers === | |||
=== Dimensions === | |||
=== Groups === | |||
=== Type Definitions === | |||
== Suggested Types not Included == | |||
Discussed in this section are types that are present in some other systems (e.g., ASN 1.1) but that are not includes in DAP 4 along with the rationale of not including them. | |||
=== Enumeration === | |||
This type will be taxing to client builders because there is an unbounded set of potential values. At the same time most (all?) clients will implement this type as a set with no actual knowledge of the set elements semantics, so it is no different than a byte or integer type with a attribute that provides a binding between (integral) formal values and String, et c., actual values. | |||
=== Boolean === | |||
The additional semantic information provided by this type seems very limited given the cost associated with each additional data type in a protocol such as DAP. | |||
=== Date/Time === | |||
Of all the types suggested but not included, this has the most potential. Unfortunately, it's very unlikely that this type would be implemented correctly by a majority of servers. It is certainly possible to include it in the DAP itself, but servers would have to provide a mapping from the encoding of date/time in each relevant data source to some sort of a standard representation (e.g., ISO 8601). That seems unlikely and thus it seems most likely that a date/time type would not be used consistently. A better solution is to use Attributes which provide the potential for third party mediation or augmentation. | |||
== Attributes == | == Attributes == | ||
Revision as of 22:40, 20 May 2009
Introduction
Overall Operation
Data Types
DAP 4 will have a small increase in supported data types. All of the DAP 2 data types describes in ESE RFC 004.11 will be supported with their existing definition with the exceptions that Grid will be expanded so that it can be used in more situations and strings will comply with UTF-8. The additional types will support 64-bit integers, an Opaque type that can be used for data objects like JPEG images, Groups that can be used to build logical collections as in NetCDF4 or HDF5 (with some limitations over HDF5's definition of Group) and Dimensions. In addition, the server-side of DAP 4 will provide for Type Definitions which will allow data systems that have these to be presented with better fidelity than DAP 2.
Support for Existing Types
Changes in the Definition of Grid
Changes to the String Type
New Datatypes
Opaque
64-bit Integers
Dimensions
Groups
Type Definitions
Suggested Types not Included
Discussed in this section are types that are present in some other systems (e.g., ASN 1.1) but that are not includes in DAP 4 along with the rationale of not including them.
Enumeration
This type will be taxing to client builders because there is an unbounded set of potential values. At the same time most (all?) clients will implement this type as a set with no actual knowledge of the set elements semantics, so it is no different than a byte or integer type with a attribute that provides a binding between (integral) formal values and String, et c., actual values.
Boolean
The additional semantic information provided by this type seems very limited given the cost associated with each additional data type in a protocol such as DAP.
Date/Time
Of all the types suggested but not included, this has the most potential. Unfortunately, it's very unlikely that this type would be implemented correctly by a majority of servers. It is certainly possible to include it in the DAP itself, but servers would have to provide a mapping from the encoding of date/time in each relevant data source to some sort of a standard representation (e.g., ISO 8601). That seems unlikely and thus it seems most likely that a date/time type would not be used consistently. A better solution is to use Attributes which provide the potential for third party mediation or augmentation.
Attributes
Names
Services
Examples
Responses
Persistent representations
