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

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
No edit summary
Line 1: Line 1:
[[Category:Development|Development]][[Category:DAP4|DAP4]]
[[OPULS_Development| << Back to OPULS Development]]
==Introduction==
==Introduction==



Revision as of 19:31, 12 April 2012

<< Back to OPULS Development

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