W3C home > Mailing lists > Public > uri@w3.org > September 2010

Re: URI Template 04 Questions

From: Thomas Van Lenten <thomasvl@google.com>
Date: Tue, 28 Sep 2010 11:04:19 -0400
Message-ID: <AANLkTi=HEG3qz6O4U3j0aArh6mo5Y2m2myAM5UzA0+6N@mail.gmail.com>
To: "Cheney, Austin" <Austin.Cheney@travelocity.com>
Cc: Mike Burrows <mjb@asplake.co.uk>, "uri@w3.org" <uri@w3.org>
On Tue, Sep 28, 2010 at 11:01 AM, Cheney, Austin
<Austin.Cheney@travelocity.com> wrote:
> Thomas,
>
> I am not sure of what your objective is with regard to the JSON
> encapsulation.  Since you are talking about JSON then I will speak
> programmatically from a JavaScript perspective.  If you are able to
> interpret JSON without use of a JavaScript interpreter then please
> ignore this email.

The questions are in reference to the URI Template (draft) spec -
http://tools.ietf.org/html/draft-gregorio-uritemplate-04

TVL

>
>>         "{list}" -> "val1,val3"
>> or
>>         "{list}" -> "val1,,val3"
>>
>>         "{keys1}" -> "key2,val2"
>> or
>>         "{keys1}" -> "key1,,key2,val2"
>>
>>         "{keys2}" -> "key1,val1"
>> or
>>         "{keys2}" -> ",val2,key1,val1"
>
> In the first instance of each of the three examples it appears that
> indexes are collapsed to support only the minimum number of variables
> while the second instance of each of the examples an empty index is
> preserved in the absence of a supplied variable.
>
> The first instances are fine if you know in advance that the indexes are
> collapsed before interpreting the JSON, because then you can perform one
> of two precautions.  The first precaution is to pre append a label to
> the variables so that the receiving logic knows to what each of the
> variables are without regard for their location in the index of the keys
> and list objects.  Some examples of pre appending a label could be:
>
>   val1 = ["val1", val1];
>   val1 = "val1|" + val1;
>
> The second precaution to take to prevent ambiguity when index location
> becomes irrelevant is to perform some sort of associative logic that
> either prevents the inclusion of certain variables under certain
> conditions, but selectivity is only relevant if such logical conditions
> are equally known to any interpreting logic, or builds a parallel object
> of labels and an equal number of indexes.  I have found that parallel
> objects and arrays are the most efficient means of processing large
> objects and arrays in JavaScript.  Here is an example:
>
>   list = {val1, val3};
>   label = {lab1, lab3};
>
> This is the most efficient means of processing because the number of
> indexes are collapsed, and that results in the fewest number of loop
> iterations.  Since a parallel object contains the labels and not the
> object of value you can target each object respectively to find what you
> need by referring to the same identical index.  Please be aware that
> when using parallel objects/arrays each index, as well as nested index,
> must be created in tandem or one must be based entirely off the other.
> All that matters with this scheme is that the indexes are always in
> sync, and if those indexes become mismatched you will be interpreting
> data in error.  I have an example at
> http://prettydiff.com/markup_beauty.js, where the build, cinfo, token,
> and length arrays are all parallel.
>
> It should be noted that for large data sets parallel objects/arrays
> requires a larger addressable space in memory, but I have never seen
> this become a problem.  Most performance increases typically result from
> reduction of function calls and conditions in loops, except in
> TraceMonkey.
>
> The second instance of each of your three examples requires
> significantly less logic to interpret the objects and a little less
> logic to build out those objects.  This method may be faster for you to
> write, but it will be less efficient to process against large indexes.
> Since there is less logic to write that means there is less data to
> transmit across the wire if the objects are not created prior to
> transport.  When writing JavaScript I have found it is better for the
> user experience to send slightly larger amounts of logic if that
> increase in logic results in vastly superior performance.
>
> If this does not go across the wire, such as server side JavaScript
> interpretation, then you have to be entirely aware of what executes the
> JavaScript.  JavaScript interpretation is by no means fast.  It is the
> slowest language I have ever seen.  Keep in mind that PHP and Perl are
> also interpreted languages, but they are radically faster than
> JavaScript even after the advances in modern interpretation engines such
> as Presto and V8.  If external factors are trigging the execution of
> JavaScript interpretation then by all means write the code to be as
> efficient to process as possible, otherwise you will spend more money
> then you need to on maintaining servers.
>
> Thanks,
>
> Austin Cheney, Travelocity User Experience
> CISSP TS/SCI
>
Received on Tuesday, 28 September 2010 15:37:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC