After ignoring all of Isaac's good advice (sorry) I've decided to stick with
a single tag (<data>) to describe all data and positional fieldlists. I
can't fully explain it... but it definitely feels simpler to me.
However the problem of verbosity still exists (for recordsets especially).
Consider a recordset that consists of three columns of data: "id", "name"
and "dob". Say it represents a search result. One way to represent this in
my dialect is as a single object containing an array for each column of
data:
<data type="object" fields="id, name, dob, ">
<data type="array">
<data type="number">3535</data>
<data type="number">3553</data>
<data type="number">2356</data>
</data>
<data type="array">
<data type="string">Jim Davis</data>
<data type="string">Carol Davis</data>
<data type="string">Paxton Davis</data>
</data>
<data type="array">
<data type="date">04/23/1971</data>
<data type="date">02/12/1970</data>
<data type="date">10/15/1998</data>
</data>
</data>
This is fairly concise - everything I'm concerned with (JavaScript, Java,
ColdFusion) can understand and represent this natively. However the
structure just doesn't represent the idea of the data very well - as a group
of records.
To do that we could represent the data as an array containing a separate
object for each row:
<data type="array">
<data type="object" fields="id, name, dob, ">
<data type="number">3535</data>
<data type="string">Jim Davis</data>
<data type="date">04/23/1971</data>
</data>
<data type="object" fields="id, name, dob, ">
<data type="string">Carol</data>
<data type="string">Anne</data>
<data type="string">Davis</data>
</data>
<data type="object" fields="id, name, dob, ">
<data type="number">2356</data>
<data type="string">Paxton Davis</data>
<data type="date">10/15/1998</data>
</data>
</data>
This is closer to what I need ultimately or could be used as is (although
most likely I'd want to convert each of these objects to a custom class
anyway).
But it's clear that this is more verbose than the first. When the field
lists become longer or the number of records larger this solution quickly
results in huge data packets.
In both cases however we have the same problem: repetition of metadata.
Both repeat the type for every cell or property for example even tho;
they're all the same. The second also repeats the field list for every row.
One idea I'm toying with is just to not deal with it at all. Even at its
worst this dialect is almost always smaller than an equivalent WDDX or SOAP
packet and they're doing okay, right?
I may very well end up there. However another idea I had was to create some
type of "metadata" that could be applied to multiple nodes. At first I was
only concerned with the "fields" attribute but then it occurred to me that I
could use the same structure I've already got. Consider the following
version of the second packet:
<metadata label="Client" type="object" fields="id, name, dob, ">
<data type="number" />
<data type="string" />
<data type="date" />
</metadata>
<data type="array">
<data label="Client">
<data>3535</data>
<data>Jim Davis</data>
<data>04/23/1971</data>
</data>
<data label="Client">
<data>Carol</data>
<data>Anne</data>
<data>Davis</data>
</data>
<data label="Client">
<data>2356</data>
<data>Paxton Davis</data>
<data>10/15/1998</data>
</data>
</data>
In this example the <metadata> tag contains all of the type information for
the individual rows. The first example above might look like this (if we
assume that, for arrays, the definition of the first cell applies to all
cells):
<metadata label="ResultList" type="object" fields="id, name, dob, ">
<data type="array">
<data type="number" />
</data>
<data type="array">
<data type="string" />
</data>
<data type="date">
<data type="date" />
</data>
</metadata>
<data label="ResultList">
<data>
<data>3535</data>
<data>3553</data>
<data>2356</data>
</data>
<data>
<data>Jim Davis</data>
<data>Carol Davis</data>
<data>Paxton Davis</data>
</data>
<data>
<data>04/23/1971</data>
<data>02/12/1970</data>
<data>10/15/1998</data>
</data>
</data>
In both cases the "label" attribute is used to link the data with the meta
data. For any <data> tag using the label the attributes of the
corresponding <metadata> tag would be applied in the same structure.
Parsing would be more complex... I see essentially a two pass parser. The
first pass determines if there are any <metadata> tags and applies the
parameters within them to any labeled elements. This essentially converts
our last two examples to the first two examples.
The second pass parses the packet normally.
Use of <metadata> would, of course, be completely optional. It would only
be needed in circumstances where controlling the size of the packet is more
important that parsing performance.
What do you think?
For some reason I really like this whole concept... it seems elegant to me.
I like elegant.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169460
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/5
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:5
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.5
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
