[JSON] Stable Child Resource Order
hi, the JSON serialization that sling uses to generate json responses assumes that the consumer creates a object representation that has a stable child object ordering. although this is not mandated neither by JSON [0] nor by ECMA [1] most of the ecma runtimes have stable child objects. but for example the default org.json.JSONObject uses a plain HashMap for the child objects, that's why sling has an extended version that uses a LinkedHashMap. i recently played with the JSONDecoder in Flash which just creates plain AS Objects, which don't have a stable order, so i had to create an own decoder that feeds a specialized AS JSONObject. I assume that other runtimes (.NET, PHP, etc) might suffer from the same problem. see also [2] and [3] that talk about that. especially when dealing with WCM content, where the ordering is important (order of paragraphs, order of child documents, etc), this might be a problem that such implementations can't rely on their default json lib, when they want to access a resource tree remotely. this all leads to the question, if the JSON response of sling should be extended to alleviate the transport of a stable child resource ordering. the probably simplest and backward compatible extension could be to additionally include an array with the child resource names, for example: { "p1": "hello world", "a": { ... }, "b": { ... }, "*": ["a", "b"] } the special array "*" would contain the names of the child resources in the order provided by the resource resolver. the special name "*" should minimize the risk for collisions with existing nv pairs. also note, that the order of the "properties" is not relevant to clients (as, for example, it is not given for JCR properties, xml attributes, nv pairs in java properties files, etc). the resource resolver could even be extended to expose the information about if child resource ordering is given at all (for example only jcr nodes with 'orderable child nodes' have this behavior). if the oder can not be provided by the underlying system, the "*" array should be omitted. including this array per default would generate some overhead by increasing response sizes and client memory consumption and also decreasing decoding performance. so it might makes sense to either make it configurable, or to deduce it somehow from the request (special header, special extension, special selector). also, i would only include it, if the depth level is high enough to already include the child resources (e.g. foo.0.json would not include the "*" array). WDYT ? regards, toby [0] http://www.json.org/javadoc/org/json/JSONObject.html (A JSONObject is an unordered collection of name/value pairs...) [1] http://interglacial.com/javascript_spec/a-4.html#a-4.3.3 [2] http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-javascript [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
Re: [JSON] Stable Child Resource Order
Hi, Am Donnerstag, den 07.04.2011, 06:47 +0100 schrieb Tobias Bocanegra: > hi, > the JSON serialization that sling uses to generate json responses > assumes that the consumer creates a object representation that has a > stable child object ordering. although this is not mandated neither by > JSON [0] nor by ECMA [1] To be clear: The ECMAScript standard explicitly states, that there is *no* order to be assumed amongst the properties. As a consequence JSON (and the JSON library we use) do *not* guarantee an order. > most of the ecma runtimes have stable child > objects. which is "legal" according to the spec but leads to false assumptions, unfortunately > but for example the default org.json.JSONObject uses a plain > HashMap for the child objects, that's why sling has an extended > version that uses a LinkedHashMap. > > i recently played with the JSONDecoder in Flash which just creates > plain AS Objects, which don't have a stable order, so i had to create > an own decoder that feeds a specialized AS JSONObject. I assume that > other runtimes (.NET, PHP, etc) might suffer from the same problem. No, they don't suffer from the problem. They are perfectly right. We suffer by assuming an order. > see also [2] and [3] that talk about that. > > especially when dealing with WCM content, where the ordering is > important (order of paragraphs, order of child documents, etc), this > might be a problem that such implementations can't rely on their Again (sorry): We should not rely because the expectations may and will fail... (as we now see in reality, and I have heard some browser vendors even don't have ordered properties any longer ...) > default json lib, when they want to access a resource tree remotely. > > this all leads to the question, if the JSON response of sling should > be extended to alleviate the transport of a stable child resource > ordering. the probably simplest and backward compatible extension > could be to additionally include an array with the child resource > names, for example: > > { > "p1": "hello world", > "a": { ... }, > "b": { ... }, > "*": ["a", "b"] > } > > the special array "*" would contain the names of the child resources > in the order provided by the resource resolver. the special name "*" > should minimize the risk for collisions with existing nv pairs. also > note, that the order of the "properties" is not relevant to clients > (as, for example, it is not given for JCR properties, xml attributes, > nv pairs in java properties files, etc). > > the resource resolver could even be extended to expose the information > about if child resource ordering is given at all (for example only jcr > nodes with 'orderable child nodes' have this behavior). if the oder > can not be provided by the underlying system, the "*" array should be > omitted. > > including this array per default would generate some overhead by > increasing response sizes and client memory consumption and also > decreasing decoding performance. so it might makes sense to either > make it configurable, or to deduce it somehow from the request > (special header, special extension, special selector). also, i would > only include it, if the depth level is high enough to already include > the child resources (e.g. foo.0.json would not include the "*" array). > > WDYT ? I like the idea of a special property and I like the "special" character used. Maybe we could just use a regular "illegal" property name like ":child-node-order" or ":sling:child-node-order" instead of a single character. Using the colon prefix would also make sure, that such a property if sent back to the Sling POST Servlet would just be ignored. I am not so much concerned with performance (I would assume the ordering information overhead is minimal). I am more concerned with backwards compatibility. Unfortunately existing clients will not expect additional properties and thus side effects may happen if we just add them. So in the interest of stability, I would suggest we add a required selector to get back the child node order property. Regarding information on supported child node ordering: I would assume that we could add such information to the ResourceMetaData of JCR Node Resources. To conclude: +1 to extend JcrNodeResource to provide the orderable child node attribute of the node type to the ResourceMetaData +1 to optionally provide a synthetic child node order property +1 to requiring a new selector to request the child node order property +1 to omit the child node order property if the parent node does not support child node ordering (as indicated by the ResourceMetaData property). Regards Felix > > regards, toby > > [0] http://www.json.org/javadoc/org/json/JSONObject.html (A JSONObject > is an unordered collection of name/value pairs...) > [1] http://interglacial.com/javascript_spec/a-4.html#a-4.3.3 > [2] > http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-javascript > [3] http://ol
Re: [JSON] Stable Child Resource Order
On 07.04.11 09:17, "Felix Meschberger" wrote: >>the special array "*" would contain the names of the child resources >> in the order provided by the resource resolver. > Maybe we could just use a regular "illegal" property name like >":child-node-order" or ":sling:child-node-order" instead of a single >character. What about using ":order"? And the selector would be "order" as well (e.g. "foo.order.infinity.json"). Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: > On 07.04.11 09:17, "Felix Meschberger" wrote: > >>the special array "*" would contain the names of the child resources > >> in the order provided by the resource resolver. > > Maybe we could just use a regular "illegal" property name like > >":child-node-order" or ":sling:child-node-order" instead of a single > >character. > > What about using ":order"? The problem is that ":order" already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes > > And the selector would be "order" as well (e.g. "foo.order.infinity.json"). sounds reasonable to me. Regards Felix
Re: [JSON] Stable Child Resource Order
On 07.04.11 13:31, "Felix Meschberger" wrote: >The problem is that ":order" already is used by the Sling POST Servlet >to define the order of newly inserted nodes... Ah, yes, I thought that one was named differently (should have checked :-)). But maybe this is ok? In all the cases I know, one never does a full round-trip, but rather uses some kind of form / dialog that defines the actual items to show and to update, so if ":order" is not part of it (or not sent along), there will be no conflict. But of course, I don't know what other Sling users are doing. >While I don't think we are walking into a collision here in the near >future, I would like to either not use that name or correlate an >potential update of Sling POST Servlet's use of the parameter, e.g. to >define/update the order of nodes If it is 100% round-trippable (i.e. adding support for :order as an array to the Sling POST servlet), why not? Inventing new names adds complexity and potential for confusion... Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
why not just render the ordered child nodes as a json array? On Apr 7, 2011 10:22 AM, "Alexander Klimetschek" wrote: > On 07.04.11 13:31, "Felix Meschberger" wrote: >>The problem is that ":order" already is used by the Sling POST Servlet >>to define the order of newly inserted nodes... > > Ah, yes, I thought that one was named differently (should have checked > :-)). > > But maybe this is ok? In all the cases I know, one never does a full > round-trip, but rather uses some kind of form / dialog that defines the > actual items to show and to update, so if ":order" is not part of it (or > not sent along), there will be no conflict. But of course, I don't know > what other Sling users are doing. > >>While I don't think we are walking into a collision here in the near >>future, I would like to either not use that name or correlate an >>potential update of Sling POST Servlet's use of the parameter, e.g. to >>define/update the order of nodes > > If it is 100% round-trippable (i.e. adding support for :order as an array > to the Sling POST servlet), why not? Inventing new names adds complexity > and potential for confusion... > > Regards, > Alex > > -- > Alexander Klimetschek > Developer // Adobe (Day) // Berlin - Basel > > > >
Re: [JSON] Stable Child Resource Order
On 07.04.11 19:38, "Eric Norman" wrote: >why not just render the ordered child nodes as a json array? This would be much more incompatible with the existing way of using a JSON object, and then you need to think about what the name for the special property designated for the child node's names must be. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
On 07.04.11 20:46, "Alexander Klimetschek" wrote: >On 07.04.11 19:38, "Eric Norman" wrote: >>why not just render the ordered child nodes as a json array? > >This would be much more incompatible with the existing way of using a JSON >object, and then you need to think about what the name for the special >property designated for the child node's names must be. ... and you can no longer quickly access the sub tree by name in javascript: root.child.grandchild.property = "foo" Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
thanks felix, i think we go the same way here - maybe it was not so clear from my wording :-) all i'm saying is: sling uses a JSON like format to present a resource tree which can cause problems for JSON/ECMA compliant clients that don't implement stable child object ordering. as mentioned by [3] this is very unfortunate that ECMA script engines don't do that. such clients currently can't re-use the existing JSON->Object decoder and need to implement it themselves. > Maybe we could just use a regular "illegal" property name like > ":child-node-order" or ":sling:child-node-order" instead of a single character sling is all about resources - not nodes, right :-) so i'd rather go for: ":child-resource-names" or a shorter ":child-names" regards, toby [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger wrote: > Hi, > > Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander > Klimetschek: >> On 07.04.11 09:17, "Felix Meschberger" wrote: >> >>the special array "*" would contain the names of the child resources >> >> in the order provided by the resource resolver. >> > Maybe we could just use a regular "illegal" property name like >> >":child-node-order" or ":sling:child-node-order" instead of a single >> >character. >> >> What about using ":order"? > > The problem is that ":order" already is used by the Sling POST Servlet > to define the order of newly inserted nodes... > > While I don't think we are walking into a collision here in the near > future, I would like to either not use that name or correlate an > potential update of Sling POST Servlet's use of the parameter, e.g. to > define/update the order of nodes > >> >> And the selector would be "order" as well (e.g. "foo.order.infinity.json"). > > sounds reasonable to me. > > Regards > Felix > > >
Re: [JSON] Stable Child Resource Order
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman wrote: > why not just render the ordered child nodes as a json array? that's another way, yes. but then you need to transport the resource name in a special property. eg: { name: "foo", properties: { }, children: [ { name:"child1", properties: { ... }, children : [ ...] }, { ... } ] but this would not be backward compatible and is more complex, too. regards, toby
Re: [JSON] Stable Child Resource Order
Yes, but if order is important it seems more correct to send an array. And adding a psuedo 'order' property isn't backward compatible either. On Thu, Apr 7, 2011 at 11:26 AM, Tobias Bocanegra wrote: > On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman > wrote: > > why not just render the ordered child nodes as a json array? > > that's another way, yes. but then you need to transport the resource > name in a special property. eg: > > { > name: "foo", > properties: { > > }, > children: [ > { > name:"child1", > properties: { ... }, > children : [ ...] > }, > { > ... > } > ] > > but this would not be backward compatible and is more complex, too. > regards, toby
Re: [JSON] Stable Child Resource Order
Is there any reason why you can't just make a custom script to output whatever JSON format you want? I'm not convinced this has usefulness outside your use case that would warrant changing the generic format. On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegra wrote: > thanks felix, > i think we go the same way here - maybe it was not so clear from my wording > :-) > all i'm saying is: sling uses a JSON like format to present a resource > tree which can cause problems for JSON/ECMA compliant clients that > don't implement stable child object ordering. as mentioned by [3] this > is very unfortunate that ECMA script engines don't do that. > such clients currently can't re-use the existing JSON->Object decoder > and need to implement it themselves. > > > Maybe we could just use a regular "illegal" property name like > > ":child-node-order" or ":sling:child-node-order" instead of a single > character > sling is all about resources - not nodes, right :-) so i'd rather go for: > > ":child-resource-names" or a shorter ":child-names" > > regards, toby > > [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html > > On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger > wrote: > > Hi, > > > > Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander > > Klimetschek: > >> On 07.04.11 09:17, "Felix Meschberger" wrote: > >> >>the special array "*" would contain the names of the child resources > >> >> in the order provided by the resource resolver. > >> > Maybe we could just use a regular "illegal" property name like > >> >":child-node-order" or ":sling:child-node-order" instead of a single > >> >character. > >> > >> What about using ":order"? > > > > The problem is that ":order" already is used by the Sling POST Servlet > > to define the order of newly inserted nodes... > > > > While I don't think we are walking into a collision here in the near > > future, I would like to either not use that name or correlate an > > potential update of Sling POST Servlet's use of the parameter, e.g. to > > define/update the order of nodes > > > >> > >> And the selector would be "order" as well (e.g. > "foo.order.infinity.json"). > > > > sounds reasonable to me. > > > > Regards > > Felix > > > > > >
Re: [JSON] Stable Child Resource Order
you can just add a feed.json.jsp file and use {resourcename}.feed.json to render your custom output HTH Ruben On 4/7/2011 12:47 PM, Eric Norman wrote: Is there any reason why you can't just make a custom script to output whatever JSON format you want? I'm not convinced this has usefulness outside your use case that would warrant changing the generic format. On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegra wrote: thanks felix, i think we go the same way here - maybe it was not so clear from my wording :-) all i'm saying is: sling uses a JSON like format to present a resource tree which can cause problems for JSON/ECMA compliant clients that don't implement stable child object ordering. as mentioned by [3] this is very unfortunate that ECMA script engines don't do that. such clients currently can't re-use the existing JSON->Object decoder and need to implement it themselves. Maybe we could just use a regular "illegal" property name like ":child-node-order" or ":sling:child-node-order" instead of a single character sling is all about resources - not nodes, right :-) so i'd rather go for: ":child-resource-names" or a shorter ":child-names" regards, toby [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger wrote: Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: On 07.04.11 09:17, "Felix Meschberger" wrote: the special array "*" would contain the names of the child resources in the order provided by the resource resolver. Maybe we could just use a regular "illegal" property name like ":child-node-order" or ":sling:child-node-order" instead of a single character. What about using ":order"? The problem is that ":order" already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes And the selector would be "order" as well (e.g. "foo.order.infinity.json"). sounds reasonable to me. Regards Felix
Re: [JSON] Stable Child Resource Order
On 07.04.11 21:47, "Eric Norman" wrote: >Is there any reason why you can't just make a custom script to output >whatever JSON format you want? I'm not convinced this has usefulness >outside your use case that would warrant changing the generic format. That's what we are discussing: how to integrate it as simple as possible without breaking things ;-) Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
hi, the current default render servlet for JSON [0] uses the described format. as there are already clients relying on this format, we can't just change it. therefore adding an additional name array keeps the format backward compatible and solves the problem. regards, toby [0] http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/get/src/main/java/org/apache/sling/servlets/get/impl/helpers/JsonRendererServlet.java?view=markup On Thu, Apr 7, 2011 at 12:52 PM, Ruben Reusser wrote: > you can just add a feed.json.jsp file and use {resourcename}.feed.json > to render your custom output > > HTH > > Ruben > > On 4/7/2011 12:47 PM, Eric Norman wrote: >> Is there any reason why you can't just make a custom script to output >> whatever JSON format you want? I'm not convinced this has usefulness >> outside your use case that would warrant changing the generic format. >> >> >> On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegra wrote: >> >>> thanks felix, >>> i think we go the same way here - maybe it was not so clear from my wording >>> :-) >>> all i'm saying is: sling uses a JSON like format to present a resource >>> tree which can cause problems for JSON/ECMA compliant clients that >>> don't implement stable child object ordering. as mentioned by [3] this >>> is very unfortunate that ECMA script engines don't do that. >>> such clients currently can't re-use the existing JSON->Object decoder >>> and need to implement it themselves. >>> Maybe we could just use a regular "illegal" property name like ":child-node-order" or ":sling:child-node-order" instead of a single >>> character >>> sling is all about resources - not nodes, right :-) so i'd rather go for: >>> >>> ":child-resource-names" or a shorter ":child-names" >>> >>> regards, toby >>> >>> [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html >>> >>> On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger >>> wrote: Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: > On 07.04.11 09:17, "Felix Meschberger" wrote: >>> the special array "*" would contain the names of the child resources >>> in the order provided by the resource resolver. >> Maybe we could just use a regular "illegal" property name like >> ":child-node-order" or ":sling:child-node-order" instead of a single >> character. > What about using ":order"? The problem is that ":order" already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes > And the selector would be "order" as well (e.g. >>> "foo.order.infinity.json"). sounds reasonable to me. Regards Felix >
Re: [JSON] Stable Child Resource Order
While I see the reasons behind just adding an order property, I agree with Eric that if you want to have an ordering use an array - maps rarely have an order regardless of the language. This is about adding a "new" format, so both client and server needs to implement this - therefore I think we're really free to do the right thing. I don't see the need that the enhanced format is nearly the same as the old one. Regards Carsten Alexander Klimetschek wrote > On 07.04.11 21:47, "Eric Norman" wrote: > >> Is there any reason why you can't just make a custom script to output >> whatever JSON format you want? I'm not convinced this has usefulness >> outside your use case that would warrant changing the generic format. > > That's what we are discussing: how to integrate it as simple as possible > without breaking things ;-) > > Regards, > Alex > -- Carsten Ziegeler cziege...@apache.org
Re: [JSON] Stable Child Resource Order
well, as alex said, the format is quite cool and very useful when it's used in an ecma script environment. and i guess the order is not often used. and if you wish to iterate, then you can just use the child-names array, eg: for (var name in obj[":child-names"]) { var child = obj[name]; } regards, toby On Thu, Apr 7, 2011 at 11:01 PM, Carsten Ziegeler wrote: > While I see the reasons behind just adding an order property, I agree > with Eric that if you want to have an ordering use an array - maps > rarely have an order regardless of the language. > This is about adding a "new" format, so both client and server needs to > implement this - therefore I think we're really free to do the right > thing. I don't see the need that the enhanced format is nearly the same > as the old one. > > Regards > Carsten > > Alexander Klimetschek wrote >> On 07.04.11 21:47, "Eric Norman" wrote: >> >>> Is there any reason why you can't just make a custom script to output >>> whatever JSON format you want? I'm not convinced this has usefulness >>> outside your use case that would warrant changing the generic format. >> >> That's what we are discussing: how to integrate it as simple as possible >> without breaking things ;-) >> >> Regards, >> Alex >> > > > -- > Carsten Ziegeler > cziege...@apache.org >
Re: [JSON] Stable Child Resource Order
Tobias Bocanegra wrote > well, as alex said, the format is quite cool and very useful when it's > used in an ecma script environment. and i guess the order is not often > used. Well...if the order is not used, the old format is perfect, right? :) > and if you wish to iterate, then you can just use the > child-names array, eg: Yes, but iterating over an array is easy as well :) So, it boils down to: - abusing a map with a special order property vs - using an array with a special name property :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [JSON] Stable Child Resource Order
On 08.04.11 08:01, "Carsten Ziegeler" wrote: >maps rarely have an order regardless of the language. A linked map is not an unusual data structure. As Tobi noted, WCM/CMS is a prominent use case. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
Hi, Am Freitag, den 08.04.2011, 12:04 +0100 schrieb Alexander Klimetschek: > On 08.04.11 08:01, "Carsten Ziegeler" wrote: > >maps rarely have an order regardless of the language. > > A linked map is not an unusual data structure. As Tobi noted, WCM/CMS is a > prominent use case. Yes, but: the Map interface itself has no defined order: "Some map implementations, like the TreeMap class, make specific guarantees as to their order; others, like the HashMap class, do not." So, if you encounter a "Map" (not a TreeMap or LinkedHashMap), you must not depend on any key ordering ... And most Map implementations used are in fact neither TreeMap nor LinkedHashMap. Regards Felix
Re: [JSON] Stable Child Resource Order
Hi, Am Donnerstag, den 07.04.2011, 20:46 +0100 schrieb Eric Norman: > Yes, but if order is important it seems more correct to send an array. And > adding a psuedo 'order' property isn't backward compatible either. I see, but ... As has been said, the current JSON export has the nice "side-effect" of being an exact view on the Sling Resource Tree (the repository mostly, but not exclusively). I think this is one of the value propositions of our JSON export. So, I would like to keep this. Adding a new property ":order" (remark the leading colon) on request, we can provide the ordering information in a special property which should/cannot be mistaken for a regular property (because the leading colon would be an illegale JCR name). Also, the ":order" would only be sent on-request. So, I think we are backwards compatible and the workaround IMHO is acceptable. Regards Felix > > On Thu, Apr 7, 2011 at 11:26 AM, Tobias Bocanegra wrote: > > > On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman > > wrote: > > > why not just render the ordered child nodes as a json array? > > > > that's another way, yes. but then you need to transport the resource > > name in a special property. eg: > > > > { > > name: "foo", > > properties: { > > > > }, > > children: [ > > { > > name:"child1", > > properties: { ... }, > > children : [ ...] > > }, > > { > > ... > > } > > ] > > > > but this would not be backward compatible and is more complex, too. > > regards, toby
Re: [JSON] Stable Child Resource Order
On 11.04.11 05:50, "Felix Meschberger" wrote: >Am Freitag, den 08.04.2011, 12:04 +0100 schrieb Alexander Klimetschek: >> On 08.04.11 08:01, "Carsten Ziegeler" wrote: >> >maps rarely have an order regardless of the language. >> >> A linked map is not an unusual data structure. As Tobi noted, WCM/CMS >>is a >> prominent use case. > >Yes, but: the Map interface itself has no defined order: "Some map >implementations, like the TreeMap class, make specific guarantees as to >their order; others, like the HashMap class, do not." > >So, if you encounter a "Map" (not a TreeMap or LinkedHashMap), you must >not depend on any key ordering ... > >And most Map implementations used are in fact neither TreeMap nor >LinkedHashMap. Yes, I agree. However,this is "just" the way the abstractions in the Java Collections API have been designed. With "unusual data structure" I was actually meaning use-cases rather than specific data structure concepts in languages such as Java. For a protocol-level data structure you want to be language-independent, and focus on what is needed. Not sure if I wrote that already: it is really unfortunate that the order is excluded from JSON (which only comes from the ECMAscript definition) when the serialization format already keeps the ordering so easily. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel