DAP4: Constructing a DDX from a Query - Revision history

DennisHeimbigner at 20:00, 13 April 2012

2012-04-13T20:00:54Z

← Older revision		Revision as of 20:00, 13 April 2012
Line 12:		Line 12:
	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.		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:		Initial thoughts based on my "[[DAP4: Possible Notation for Server Commands \| Possible Notation for Server Commands]]" document.
	# 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		# All functions have a defined "return type". Since, unfortunately, DAP4 -- like CDM -- has no notion of separately defined type, the return type of a function would be defined as a variable possibly nested in some set of groups and with some associated attributes.
			# 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.		# 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.		# As a consequence of #3, rules must be defined for merging the output DATADDX of multiple expressions into a single DATADDX. The simplest merge might operate as follows:
			## A tree of groups is defined using the groups that are associated with the return type of an included expression (see #1 above).
			## The variables, with their attributes, are inserted into the group tree. If there are duplicate variables, then an error is reported (need a better soln for this case).


	''Dennis Heimbigner''		''Dennis Heimbigner''

DennisHeimbigner at 19:31, 12 April 2012

2012-04-12T19:31:40Z

← Older revision		Revision as of 19:31, 12 April 2012
Line 1:		Line 1:
			[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
			[[OPULS_Development\| << Back to OPULS Development]]

	==Introduction==		==Introduction==

DennisHeimbigner at 19:30, 12 April 2012

2012-04-12T19:30:41Z

← Older revision		Revision as of 19:30, 12 April 2012
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''

DennisHeimbigner: moved DAP4: DDX Constructing a DDX from a Query to DAP4: Constructing a DDX from a Query

2012-04-12T19:06:47Z

moved DAP4: DDX Constructing a DDX from a Query to DAP4: Constructing a DDX from a Query

← Older revision	Revision as of 19:06, 12 April 2012
(No difference)

DennisHeimbigner: Created page with "# All functions have a defined "return type", which looks like a legal DDX minus certain things like groups, enumeration declarations, and dimension declarations; in additio..."

2012-04-12T19:04:13Z

Created page with "# <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 additio..."

New page

# <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>
# <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.