I've been asked (don't ask why) to create an XML dialect for passing data
between the client (an HTA application) and the server (I'm prototyping in
CFMX 7 but the final code will be written to WebSphere). For various
reasons (which I don't fully agree with) they refuse to use WDDX. They also
want XML (so JSON is out) and although I'd love to use SOAP it's just too
damn complicated for our time frame.
Instead of create data-specific packets I've decided to take a queue from
WDDX and create a generalized dialect for passing structured data. Since
the data will be used primarily with this client-side application I'll need
to create serialization and deserialization in JavaScript.
What I'm playing with now is the idea of a single tag... call it "data" that
takes a "type" and a "fields" attribute. ALL data is represented by various
nestings of this one tag.
The "type" attribute could be any of the following: null, object, array,
date, function, number, string, boolean. These are based directly from the
capabilities of JavaScript (like JSON, but with simple data typing).
The "fields" attribute would contain the field names (properties, keys,
whatever) for objects (I'm also toying with the idea of using the fields
list to allow for the passing of sparse arrays... but that might be getting
to complicated). The fields would relate to positionally linked data
elements.
In other words if there are three listed fields, there should be three
corresponding <data> tags containing the data for them.
In this style a simple string would be:
<data type="string">This is string!</data>
Null would be:
<data type="null" />
And so forth. Any data tag could contain either the actual data or other
data tags allowing for complex objects:
A simple array might be:
<data type="array">
<data type="number">1</data>
<data type="number">2</data>
<data type="number">3</data>
</data>
A simple object might be:
<data type="object" fields="prop1, prop2,">
<data type="string">val1</data>
<data type="string">val2</data>
</data>
A record set could be described as an object with each property referencing
a column as an array (and this is, in fact how CF internally manages
queries):
<data type="object" fields="col1, col2,">
<data type="array">
<data type="number">1</data>
<data type="number">2</data>
<data type="number">3</data>
</data>
<data type="array">
<data type="string">a</data>
<data type="string">b</data>
<data type="string">c</data>
</data>
</data>
Finally a complex JavaScript object like this:
MyComplexObject = {
FName: "Jim",
lastname: "Davis",
Children: [ { FName: "Matilda", LName: "Davis" }, { FName:
"Paxton", LName: "Davis" } ],
Spouse: { FName: "Carol", LName: "Davis" },
};
Would serialize to this:
<data type="object" fields="FName, lastname, Children, Spouse,">
<data type="string">Jim</data>
<data type="string">Davis</data>
<data type="array">
<data type="object" fields="FName, LName,">
<data type="string">Matilda</data>
<data type="string">Davis</data>
</data>
<data type="object" fields="FName, LName,">
<data type="string">Paxton</data>
<data type="string">Davis</data>
</data>
</data>
<data type="object" fields="FName, LName,">
<data type="string">Carol</data>
<data type="string">Davis</data>
</data>
</data>
So far, in "pencil" tests with various objects it's always given me the
resolution I need without being too verbose (WDDX, for example, is a VERY
verbose dialect).
I believe (am I right?) that simplifying the dialect down to one conceptual
tag should make construction of the serializers and deserializers much
simpler.
I know there's ambiguity possible. What if the number of fields doesn't
match the number of data items? What if the "fields" attribute is added to
non-object? What if I say "object" then just put a string inside. And so
on and so on.
But I think this can be handled with either simple validation and strict
errors.
I'm also not completely thrilled with the positional aspect of the "fields"
attribute... but it's dead easy to construct from any object and dead easy
to parse. I don't think it will be a big problem.
(I've also considered adding another tag "fieldset" which could take the
form of <fieldset field="prop1,prop2,prop3" name="myObject" />. Then, in an
object you could reference the fieldset instead of repeating them: <data
type="object" fieldset="myObject">. This would only reduce the size of the
packet in those cases where you're serializing lots of the same kind of
object.)
I could also take the route some have and attempt to minimize the dialect
(just use "d", "t" and "f" instead of "data", "type" and "fields" and use
single digits to represent the data types) but as much space as that would
save it's always just annoyed me...
Any thoughts on this? Data structures it couldn't handle? Huge gaping
holes in my logic on this one?
Does this sound like it would be easier or harder to work with than explicit
tags for each data type (something like <object><property
name="prop1">val1</property></object>)?
I know, as I began that there are other methods to do this... but assuming
they're not permissible, what do you think?
Thanks,
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
All-in-one: antivirus, antispam, firewall for your PC and PDA. Buy Trend Micro
PC-cillin Internet Security
http://www.houseoffusion.com/banners/view.cfm?bannerid=60
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169276
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=89.70.5
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
