Difference between revisions of "DAP4: Constructing a DDX from a Query"

From OPeNDAP Documentation
Line 1: Line 1:
# <del>All functions have a defined "return type", which looks like a legal DDX minus certain things like groups, enumeration declarations, and dimension declarations; in addition, a function may be defined to have a "void" return type, which means it is executed for its side-effects on the server</del>
+
==Introduction==
# <del>Any expression that is not assigned to a variable and does not have a void return type will have its return value returned to the caller as part of a DATADDX</del>
 
[Note, the last two items are important in and of themselves and have been moved to a separate OPULS discussion item.]
 
  
An important aspect has to do with the construction of what may be referred to as a DATADDX. It defines the structure of a DDX that is the composition of the return types of the invoked functions that will return a (possibly structured) value. I need to work this out. BUT, in any case, the resulting DATADDX may have only have a loose relation to any DDX representing the raw dataset.  This is because server-side computations will not have been represented in the original DDX, but only in the DATADDX.
+
An important aspect of query evaluation has to do with the construction of what may be referred to as a DATADDX. It defines the structure of a DDX that is returned to the caller as the result of a request to a DAP4 server.
 +
 
 +
The returned DATADDS for DAP2 was relatively well-defined as long as one did not use any server-side functions. As far as I know, how the result of such a function call was to be defined in the returned DATADDS was never formally (or even informally) defined.
 +
 
 +
It can be expected that DAP4 will make much more use of complex queries involving a combination of constraints and server-side functions. So rules must be defined as formally as possible to define what the result of any possible query will look like.
 +
 
 +
A specific problem is that the resulting DATADDX may have only have a loose relation to any DDX representing the raw dataset.  This is because server-side computations will not have been represented in the original DDX, but only in the DATADDX.
 +
 
 +
Initial thoughts:
 +
# All functions have a defined "return type", which looks like a legal DDX minus (possibly) certain things like groups.
 +
# A function may be defined to have a "void" return type, which means it is executed for its side-effects on the server
 +
# Any expression that is not assigned to a variable and does not have a void return type will have its return value returned to the caller as part of a DATADDX.
 +
# As a consequence of #3, rules must be defined for composing the output DATADDX of multiple expressions into a single DATADDX.
 +
 
 +
 
 +
''Dennis Heimbigner''

Revision as of 19:30, 12 April 2012

Introduction

An important aspect of query evaluation has to do with the construction of what may be referred to as a DATADDX. It defines the structure of a DDX that is returned to the caller as the result of a request to a DAP4 server.

The returned DATADDS for DAP2 was relatively well-defined as long as one did not use any server-side functions. As far as I know, how the result of such a function call was to be defined in the returned DATADDS was never formally (or even informally) defined.

It can be expected that DAP4 will make much more use of complex queries involving a combination of constraints and server-side functions. So rules must be defined as formally as possible to define what the result of any possible query will look like.

A specific problem is that the resulting DATADDX may have only have a loose relation to any DDX representing the raw dataset. This is because server-side computations will not have been represented in the original DDX, but only in the DATADDX.

Initial thoughts:

  1. All functions have a defined "return type", which looks like a legal DDX minus (possibly) certain things like groups.
  2. A function may be defined to have a "void" return type, which means it is executed for its side-effects on the server
  3. Any expression that is not assigned to a variable and does not have a void return type will have its return value returned to the caller as part of a DATADDX.
  4. As a consequence of #3, rules must be defined for composing the output DATADDX of multiple expressions into a single DATADDX.


Dennis Heimbigner