DAP4: VLEN proposal - Revision history

DennisHeimbigner at 14:52, 22 July 2013

2013-07-22T14:52:29Z

@@ Line 64: / Line 64: @@
 * vector
 * series
-* vlen
+* <strike>vlen</strike>
 [[User:dmh|Dennis]]
 We should use ''vlen'' only if our definition matches that of HDF4/5 ''exactly''. If our definition is the same as HDF's, then we should definitely use that name.
 Question: What does the definition of an array with two dimensions look like where the first dimension size is some fix number and the second size varies? What about the case where both sizes vary?
-[[User:Jimg|Jimg]] 14:11, 21 July 2013 (PDT)
+[[User:dmh|Dennis]] Jul 22, 2013  8:38:41 AM :

Jimg: /* Discussion */

2013-07-21T21:11:12Z

Discussion

← Older revision		Revision as of 21:11, 21 July 2013
Line 67:		Line 67:

	[[User:dmh\|Dennis]]		[[User:dmh\|Dennis]]

			We should use ''vlen'' only if our definition matches that of HDF4/5 ''exactly''. If our definition is the same as HDF's, then we should definitely use that name.

			Question: What does the definition of an array with two dimensions look like where the first dimension size is some fix number and the second size varies? What about the case where both sizes vary?

			[[User:Jimg\|Jimg]] 14:11, 21 July 2013 (PDT)

DennisHeimbigner: Created page with "DevelopmentDAP4 << Back to OPULS Development ==Background== This page is intended to provide a concrete propos..."

2013-07-21T20:44:22Z

Created page with "Development DAP4 << Back to OPULS Development ==Background== This page is intended to provide a concrete propos..."

New page

[[Category:Development|Development]][[Category:DAP4|DAP4]]
[[OPULS_Development| << Back to OPULS Development]]

==Background==
This page is intended to provide a concrete
proposal for replacing the current variable length
dimension model with a more syntactically and
semantically clear alternative.
As such it replaces a
[[DAP4: VLens (and Sequences)| previous proposal]].

==Problem Addressed==
In my opinion, the decision to treat variable length objects (''sequences''
of objects) using the '*' dimension notation is a mistake. The reason is
that (1) it requires special handling for * in the code, (2) it violates
the desired constraint that a dimension have a specific size across all
of its occurrences (at a specific point in time).

In order to rectify this, I proposed basically two alternatives.
# Define a new type constructor, temporarily called ''Sequence'' here, and analogous to the existing DAP2 Sequence construct.
# Define a new type constructor analogous to the HDF5/netcdf-4 ''vlen'' construct. So one might define as a type, <Int32*> to indicate that its type is a sequence of Int32 objects.

There is a relationship between the two proposals in that the first
is effectively equivalent to <Sequence*>.

==Proposed Solution==
Specifically, I propose we adopt alternative 1, but possibly with a keyword other than ''Sequence''.

Its semantics is that it represents an arbitrary number of instances of objects where the objects conform to the format of a Structure equivalent to the Sequence syntax.

For example, consider this sequence declaration.
<pre>
<Sequence name="s">
<Int32 name="field1"/>
</Sequence>
</pre>
It is equivalent in semantics to a sequence of
structure instances of this form.
<pre>
<Structure name="s">
<Int32 name="field1"/>
</Structure>
</pre>

The serialized representation is the obvious one. It consists of a count, N say, representing the number of objects in the sequence followed by N serialized instances of the equivalent structure.

Note that I explicitly allow arrays of Sequences to exist. For example.
<pre>
<Sequence name="s">
<Int32 name="field1"/>
<Dim name="d2"/>
<Dim size="17"/>
</Sequence>
</pre>

==Discussion==

This proposal seems to me to be the simplest solution to the VLEN problems I have identified. There is at least one drawback.
* In translating from, say, CDM, to DAP4, it will require the creation and naming of an extra Sequence construct to appear in the DMR. In some cases, this can be mitigated, but will generally be necessary.

From previous discussions, there seems to be a consensus that calling this new constructor a ''Sequence'' is undesirable because it would be confused with the DAP2 ''Sequence'' constructor. Some possible alternative names are as follows.
* vector
* series
* vlen

[[User:dmh|Dennis]]