Suggested format for data encapsulation

[Pavils Jurjans]

Hello,

I have a fairly complex project with server-side written in C# (.NET),
and client-side heavily relying on the presence on
JavaScript-compatible scripting engine. One of the features thie
project utilizes is "virtual POST", ie, client side submits the data
to the server side, using Microsoft.XMLHT TP ActiveX Object (in MSIE),
or XMLHttpRequest class in Mozilla, and when the server returns reply,
processes it in client side to run some JavaScript and manipulate with
DOM.
The thing is, I am looking for decent, not-too-verbose data
serialization encoding that would allow me to send JavaScript-type
data to the server and back. With JavaScript-type data I mean value
that could be described as one of the following:
0) null
1) numeric value
2) string value in quotes
3) boolean value: true/false
4) date value: new Date(x, y, z)
5) array: [value, value, ...]
6) object: {value:value, value:value, ...}
Here is example of the tata that I want to be able to xfer to and from
the server:
[1, "abc", true, {a:1, b:[10,11,12, new Date(x, y, z)], c:{x:"foo",
y:"bar"}}]

Until today , I used JSON (http://www.crockford.com/JSON/index.html)
notation, cause I find it short and to the point. I have wrote my own
JavaScript code for encoding and decoding the data to and from the
JSON. However, I have stumbled upon the situation that for large data
blocks the client-side scripting engine is too weak to parse it in
reasonable time, and I am forced to use another encoding. So, now I am
thinking on XML encoding. The example above could be encoded like
this:

<value type="array">
<value type="num" value="1"/>
<value type="str" value="abc"/>
<value type="bool" vaue="true"/>
<value type="object">
<value key="a" type="num" value="1"/>
<value key="b" type="array">
<value type="num" value="10"/>
<value type="num" value="11"/>
<value type="num" value="12"/>
<value type="date" value="x y z"/>
</value>
<value key="c" type="object">
<value key="x" type="str" value="foo"/>
<value key="y" type="str" value="bar"/>
</value>
</value>
</value>

Which, of course, is much more verbose, but still the shortest way I
can think of to describe the JavaScript data structures in XML. Plus,
I could do speedy parsing on the client-side using built-in XML
parsers (vs present JSON parse that is driven by series of Regex
searches that make it slow).

So, my question is, whether there is already some running initiative
on this matter, and perhaps I need not to reinvent the wheel, and
JavaScript encoding/decoding code for this serialization format is
available?

Regards,
Pavils Jurjans

[Yann-Erwan Perio]

Re: Suggested format for data encapsulation

Pavils Jurjans wrote:

Hi,
[color=blue]
> Until today , I used JSON (http://www.crockford.com/JSON/index.html)
> notation, cause I find it short and to the point. I have wrote my own
> JavaScript code for encoding and decoding the data to and from the
> JSON. However, I have stumbled upon the situation that for large data
> blocks the client-side scripting engine is too weak to parse it in
> reasonable time, and I am forced to use another encoding.[/color]
[color=blue]
> Plus,
> I could do speedy parsing on the client-side using built-in XML
> parsers (vs present JSON parse that is driven by series of Regex
> searches that make it slow).[/color]

JS Regexp engine is NFA-based, so the way you've scripted your regular
expressions may have a huge impact - regexps optimisation would be a
good lead, using standard stuff such as anchors, non-greedy operators...

However as you describe it you just seem to need a tree (as would an XML
parser would give you) - so why don't you directly eval the JSON
structure, as recommended by the author?

<URL:http://www.crockford.c om/JSON/js.html>


As for your original question, I'm aware of no tool like the one you're
searching, but OTOH I've never needed any - I'll leave to others the
Ultimate Tool Recommendation:-)


Cheers,
Yep.

[Pavils Jurjans]

Re: Suggested format for data encapsulation

Hi Yann-Erwan,
[color=blue]
> JS Regexp engine is NFA-based, so the way you've scripted your[/color]
regular[color=blue]
> expressions may have a huge impact - regexps optimisation would be a
> good lead, using standard stuff such as anchors, non-greedy[/color]
operators...

Ok, I'll try do check this... yet I'm sort of unsure if that's the way
to go. The processing of large data block still will be quite slow. Why
should the user suffer?
[color=blue]
> However as you describe it you just seem to need a tree (as would an[/color]
XML[color=blue]
> parser would give you) - so why don't you directly eval the JSON
> structure, as recommended by the author?[/color]

Because the eval is much more powerful. In case of bad formatting of
illegal features I want to throw error at the client side. eval could
do evil things - run functions, override global variables, etc. I want
to control the parsing, because it's more secure.

I came to concluction that I could shorten the XML format even more:

<array>
<num value="1"/>
<str value="abc"/>
<bool value="true"/>
<object>
<num key="a" value="1"/>
<array key="b">
<num value="10"/>
<num value="11"/>
<num value="12"/>
<time value="25-02-2005 13:11"/>
</array>
<object key="c">
<str key="x" value="foo"/>
<str key="y" value="bar"/>
</object>
</object>
</array>

If no other stardard will be suggested from the group until the end of
february, I will go on and implement this.

Regards,

Pavils