-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why not dpxl, seeing as it's not a markup language so much as a data
transfer language that happens to an XML application?
Jim Davis wrote:
+) Something that's easy to parse for JavaScript. SOAP is NOT easy to
> parse (which is, I think, why there's no generalized SOAP parser for JS).
>
> +) Something that maintains general data types. SOAP maintains complex
> datatypes (based on Java or C+). JSON doesn't offer data typing at all. I
> thought we needed a middle ground.
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
typing doesn't imply weak typing, nor does a paucity of type annotation
imply dynamic typing. For the former, see Python, which has strong
dynamic typing, and for the latter, see Haskell and ML, which both have
strong static typing through use of type inference[1].
If you're willing to extend things a little bit by including the syntax
"new X(<comma seperated list of elements)", you can represent dates and
binary data too. I don't see any need for "undefined", which can be
denoted by simple absence of data, or function, which ties things to
JavaScript even more tightly, in which case you'd might as will go the
JSON route anyway.
That said, I'm not arguing in favour of JSON so much as pointing out
that by perceived typelessness on its part is not quite the case.
I'd include some kind of explicit recordset type too.
> Three tags only (I decided to minimize them to abbreviations since I'm only
> using two tags):
>
> <dataML>: This is the wrapper tag for the packet. It can contain, first,
> any number or zero <md> tags and one <d> tag.
>
> <d>: "Data". This tag contains the data items. It can contain as many
> other <d> tags as you like in an orgasmic orgy of nesting. (By having only
> one tag we eliminate problems that XSD has with randomly appearing child
> tags.)
>
> It take three attributes:
>
> type: The type of the data. I settled on using JavaScript's
> generalized types (plus the addition of "binary"). If not provided the data
> type will default to "string". Possible values are:
> +) "object" (equivalent to a CF Struct)
> +) "array" (single dimensional with sparse arrays supported)
> +) "null"
> +) "undefined" (I'm not sure if this is actually needed yet)
> +) "string"
> +) "number"
> +) "boolean" ("true" or "false" are the only acceptable
> values.)
> +) "date"
> +) "binary" (BASE64 Data)
> +) "function" (representing a JavaScript function.
I'd say it would actually be less bulky if you changed the names of the
types into tags.
<d type="null"/>
<null/>
<d type="boolean">true</d>
<boolean>true</boolean>
> <dataML>
> <d type="object" fields="fname, mname, lname, ">
> <d type="string">Jim</d>
> <d type="null" />
> <d type="string">Davis</d>
> </d>
> </dataML>
<dpxl>
<object fields="fname,mname,lname">
<string>Jim</string>
<null/>
<string>Davis</string>
</object>
</dpxl>
{fname: "Jim", mname: null, lname: "Davis"}
> Where a simple record set could look like this:
>
> <dataML>
> <d type="array">
> <d type="object" fields="text, value,">
> <d type="string">Fund One</d>
> <d type="string">Fund01</d>
> </d>
> <d type="object" fields="text, value,">
> <d type="string">Fund Two</d>
> <d type="string">Fund02</d>
> </d>
> <d type="object" fields="text, value,">
> <d type="string">Fund Three</d>
> <d type="string">Fund03</d>
> </d>
> </d>
> </dataML>
<dpxl>
<array>
<object fields="text,value">
<string>Fund One</string>
<string>Fund01</string>
</object>
<object fields="text,value">
<string>Fund Two</string>
<string>Fund02</string>
</object>
<object fields="text,value">
<string>Fund Three</string>
<string>Fund03</string>
</object>
</array>
</dpxl>
[
{text: "Fund One", value: "Fund01"},
{text: "Fund Two", value: "Fund02"},
{text: "Fund Three", value: "Fund03"}
]
> But over large numbers of records the repetition of the metadata would
> inflate the packet terribly. So we use the <md> tag like so:
>
> <dataML>
> <md label="option">
> <d type="object" fields="text, value,">
> <d type="string" />
> <d type="string" />
> </d>
> </md>
> <d type="array">
> <d label="option" >
> <d>Fund One</d>
> <d>Fund01</d>
> </d>
> <d label="option" >
> <d>Fund Two</d>
> <d>Fund02</d>
> </d>
> <d label="option" >
> <d>Fund Three</d>
> <d>Fund03</d>
> </d>
> </d>
> </dataML>
>
> This shrinks the serialized version of the data tremendously when you want
> to return large numbers of similar objects (as with a record set).
I'd like to point out that here the <md> tag is essentially defining a
new type, so you could change this to:
<dataML>
<type name="option">
<d type="object" fields="text,value">
<d type="string" />
<d type="string" />
</d>
</type>
<d type="array">
<d type="option">
<d>Fund One</d>
<d>Fund01</d>
</d>
<d type="option">
<d>Fund Two</d>
<d>Fund02</d>
</d>
<d type="option">
<d>Fund Three</d>
<d>Fund02</d>
</d>
</d>
</dataML>
> But there are questions. Should "default data" be allowed in meta data (if
> you fill in the content of the tags should that content be used if no
> content is provided in the <d> tags)?
I'd say so, yes.
> Should metadata for the contents of an array automatically apply to ALL
> children of that array? In other words should this be legal:
Definitely. As I said, <md> is essentially a type declaration, so yes.
Mind you, such a generalisation would complicate the serialisers and
deserialisers a bit.
> Should such a thing force all children of the array to be the same?
Yes, unless you want to reserve the "undefined" type for use in <md> to
represent somewhere where the types are specified in the body.
> In most cases you won't need the <md> at all. It's ONLY needed to save
> space. All deserializers should understand it, but serializers don't have
> to implement it.
Postel's law, in a way.
K.
[1] http://en.wikipedia.org/wiki/Type_inference
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBHeImSWF0pzlQ04RAg2cAJ0WK1qdVGJuqGZlGxzNd0noAFJNAgCfYc2G
ZVpu6kKrwU3lD0RimvrOX3U=
=YcM3
-----END PGP SIGNATURE-----
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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:4:215567
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
