You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2008/01/22 10:08:25 UTC
Default JSON format (was: How does one build Sling?)
Hi,
(renaming the thread to attract attention of our JSON folks)
On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> ...The json that would be nice to have is something like this;
>
> {
> label: 'name',
> identifier: 'name',
> items:
> [
> { name:'Fruit', type:'category'},
> { name:'Cinammon', type: 'category',
> children:
> [
> { name:'Cinammon Roll', type:'poptart' },
> { name:'Brown Sugar Cinnamon', type:'poptart' },
> { name:'French Toast', type:'poptart' }
> ]
> },
> { name:'Chocolate', type: 'category'}
> ]
> }
>
> Where the only important stuff here is that child nodes should be put in a
> separate array [], not as an object to the parent node, like this;
...(snipped current format)
Ok, so basically you'd like the child nodes to be in an array named "children".
I know others on this list have more javascript experience than me,
what do people think?
> ....Also, I have difficulties understanding what to do with the
>
> "testing":
> {"jcr:primaryType":"nt:unstructured",
>
> part, since I would somehow like it to be like this;
>
> children:
> [
> {
> title: 'testing',
> jcr_primaryType: 'nt:unstructured',
> children:
> [
> { title:"test2", sling_resourceType:
> "usling/example", jcr_primaryType: "nt:unstructured", text: "Default text of
> the test node"},
> ....
> ]
> }
> ]
>
> Hmm. I really think that this would be the correct translation, now that
> I've printed it out. The problem was in choosing how to remove the current
> "name: {}" structure to move the name into the object (where it is anyway),
> like children: [{title: name....}]...
Ok, I agree that the above is more immediately understandable than the
current format.
The downside, iiuc, is that if forces the use of ".children." to
access children...well, not sure if that's a downside, let's hear what
other javascript aficionados think!
> ...Note that children is just a convenient name, and doesn't mean anything
> magic. Also, I would feel very much more comfortable not having quotes
> around property names. I understand that they're there to escape the ':' ,
> which are very magic in js and separates property names from values,
> therefore I replaced them with underscores....
IIUC, the goal with removing the quotes is only to make the JSON look
nicer, is that right?
The problem with transforming sling:resourceType to sling_resourceType
in JSON is the possible confusion in documentation and in people's
minds...I don't like that too much.
As you indicate, making other JSON renditions pluggable would be easy,
but I think we should be able to agree on a good enough default
format.
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 11:46 AM, David Nuescheler <da...@day.com> wrote:
> > Bertrand:
> > Agreed, the convention would then be to use the last selector
> > (0,1,infinity) for the recursion level, and the selector before that
> > for the JSON "flavor".
> given our current resolving i think we actually can leave this open.
> right?...
Yes we can, but if we provide some JSON flavors out of the box, wiring
selectors to them by default might be useful.
>... .../json.servlet (which handles everything that is not mapped)
> .../dojotree/json.esp (woudl deal with the server sided conversion)
>
> wouldn't that be natural? it is then up to the dojotree/json.esp to worry
> about the additional parameters... right?...
That's right, scripts have precedence over servlets, so one can always
override the defaults with scripts.
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Lars Trieloff <la...@trieloff.net>.
Right, this was one of the big revelations when working with Cocoon's
Flowscript and it works here as well.
On 22.01.2008, at 22:14, Tobias Bocanegra wrote:
> btw: in esp, it should be as simple as calling: object.toSource()
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Default JSON format (was: How does one build Sling?)
Posted by Tobias Bocanegra <to...@day.com>.
hi,
i agree with lars and david that there is no question how the escaping
is done. http://www.json.org/ defines this very clearly:
http://www.json.org/string.gif
when writing json through a standardized json-writer and reading it
with a standardized reader, there should not be any problem.
regards, toby
btw: in esp, it should be as simple as calling: object.toSource()
On 1/22/08, Lars Trieloff <la...@trieloff.net> wrote:
> Hi Everyone,
>
> I'm just catching up with the discussion and think that we should make
> sure to use properly escaped quotation marks, backslashes and
> apostropes (which can be easily implemented using a Reader) instead of
> relying on urlencode. The more portable and standard-compliant
> solution is not so hard to implement that it would justify deviating
> from the standard.
>
> So, simply replace " with \"
> ' with \'
> and \ with \
>
> For everyone who is interested in overriding JSON output in an JS or
> ESP, we should provide a helper method writeJSON() that will take a
> Javascript Object and write it as JSON to the output stream, because
> encoding Javascript in Javascript will lead to unnecessary confusion
> and clutter.
>
> regards,
>
> Lars
>
>
> On 22.01.2008, at 15:03, Peter Svensson wrote:
>
> > Hi,
> >
> > Well, I think that the need for escaping chars exist because json is
> > itself
> > just text, and if a proeprty value contains a lot of """" here and
> > there for
> > instance, it will bork the value and also the client-side javascript
> > parsing.
> >
> > This is normally no problem for simple values, when using Sling as a
> > database of sorts, but as part of my Sling resource editor, I'd liek
> > to be
> > able to insert HTML code inside a node, which contains a lot of
> > quotes, and
> > possibly even JavaScript.
> >
> > So, that's why.
> >
> > Cheers,
> > PS
> >
> > On Jan 22, 2008 2:56 PM, David Nuescheler <da...@day.com> wrote:
> >
> >> hi guys,
> >>
> >> i am still somewhat confused why we are looking into the whole
> >> escaping issue. was there an actual issue at hand?
> >>
> >> so far i have not experienced any issue with the current "escaping"
> >> and i really would stay away from something like url escaping... i
> >> simply
> >> don't see a need.
> >> am i mistaken?
> >>
> >> btw: i am happy to remove the quotes from names that don't need
> >> the quotes.
> >>
> >> regards,
> >> david
> >>
> >>
> >> On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
> >>> Ahem. :) I kind of assumed that the "sling:resourceType" property
> >>> was
> >> magic,
> >>> and anything inside it would something that could be rendered in a
> >> browser.
> >>> Maybe not.
> >>>
> >>> I think that one of the problems in learning Sling is that it
> >>> seems to
> >> be
> >>> infinitely configurable, so that you can add renderers for things
> >>> on the
> >>> fly, et.c. But if I say it this was; If there is some kind of
> >>> basic type
> >> in
> >>> Sling for content to be consumed in a browser, then that could
> >> reasonably be
> >>> decalured to be of type urlencoded String. Would that be OK.
> >>>
> >>> Also, for my current project (Bunkai editor for Sling), I don't
> >>> really
> >> need
> >>> the content int he json structure, I only need the hierarchical
> >> structure,
> >>> in array format already described, and some unique id/name that I
> >>> can
> >> use
> >>> later, when a treenode (in Dojo) is sleected, to get the actual
> >>> content.
> >>>
> >>> Cheers,
> >>> PS
> >>>
> >>> On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> >>> >
> >>> wrote:
> >>>
> >>>> On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> ...The 'meaning' of a property value is application domain
> >>>>> specific
> >>>> anyway, so
> >>>>> I think we can choose any encoding type which is reasonably
> >>>>> simple,
> >> as
> >>>> long
> >>>>> as it is documented clearly....
> >>>>
> >>>> But how do you decide (in the general case, with the default JSON
> >>>> renderer) which properties to escape() and which to send out
> >>>> unescaped?
> >>>>
> >>>> And how do you tell the client (dont' say "configuration"
> >>>> please ;-)
> >>>> which ones are escaped?
> >>>>
> >>>> -Bertrand
> >>>>
> >>>
> >>
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 6:33 PM, Lars Trieloff <la...@trieloff.net> wrote:
> ...I'm just catching up with the discussion and think that we should make
> sure to use properly escaped quotation marks, backslashes and
> apostropes...
That should already be the case - I've just added some addition tests
to JsonRenderingTest.testEscapedStrings [1] and they all pass.
If someone finds a reproducible case where escaping is wrong, I'm
happy to fix it.
-Bertrand
[1] https://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/launchpad-webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/JsonRenderingTest.java
Re: Default JSON format (was: How does one build Sling?)
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Everyone,
I'm just catching up with the discussion and think that we should make
sure to use properly escaped quotation marks, backslashes and
apostropes (which can be easily implemented using a Reader) instead of
relying on urlencode. The more portable and standard-compliant
solution is not so hard to implement that it would justify deviating
from the standard.
So, simply replace " with \"
' with \'
and \ with \
For everyone who is interested in overriding JSON output in an JS or
ESP, we should provide a helper method writeJSON() that will take a
Javascript Object and write it as JSON to the output stream, because
encoding Javascript in Javascript will lead to unnecessary confusion
and clutter.
regards,
Lars
On 22.01.2008, at 15:03, Peter Svensson wrote:
> Hi,
>
> Well, I think that the need for escaping chars exist because json is
> itself
> just text, and if a proeprty value contains a lot of """" here and
> there for
> instance, it will bork the value and also the client-side javascript
> parsing.
>
> This is normally no problem for simple values, when using Sling as a
> database of sorts, but as part of my Sling resource editor, I'd liek
> to be
> able to insert HTML code inside a node, which contains a lot of
> quotes, and
> possibly even JavaScript.
>
> So, that's why.
>
> Cheers,
> PS
>
> On Jan 22, 2008 2:56 PM, David Nuescheler <da...@day.com> wrote:
>
>> hi guys,
>>
>> i am still somewhat confused why we are looking into the whole
>> escaping issue. was there an actual issue at hand?
>>
>> so far i have not experienced any issue with the current "escaping"
>> and i really would stay away from something like url escaping... i
>> simply
>> don't see a need.
>> am i mistaken?
>>
>> btw: i am happy to remove the quotes from names that don't need
>> the quotes.
>>
>> regards,
>> david
>>
>>
>> On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
>>> Ahem. :) I kind of assumed that the "sling:resourceType" property
>>> was
>> magic,
>>> and anything inside it would something that could be rendered in a
>> browser.
>>> Maybe not.
>>>
>>> I think that one of the problems in learning Sling is that it
>>> seems to
>> be
>>> infinitely configurable, so that you can add renderers for things
>>> on the
>>> fly, et.c. But if I say it this was; If there is some kind of
>>> basic type
>> in
>>> Sling for content to be consumed in a browser, then that could
>> reasonably be
>>> decalured to be of type urlencoded String. Would that be OK.
>>>
>>> Also, for my current project (Bunkai editor for Sling), I don't
>>> really
>> need
>>> the content int he json structure, I only need the hierarchical
>> structure,
>>> in array format already described, and some unique id/name that I
>>> can
>> use
>>> later, when a treenode (in Dojo) is sleected, to get the actual
>>> content.
>>>
>>> Cheers,
>>> PS
>>>
>>> On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <bdelacretaz@apache.org
>>> >
>>> wrote:
>>>
>>>> On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com>
>>>> wrote:
>>>>
>>>>> ...The 'meaning' of a property value is application domain
>>>>> specific
>>>> anyway, so
>>>>> I think we can choose any encoding type which is reasonably
>>>>> simple,
>> as
>>>> long
>>>>> as it is documented clearly....
>>>>
>>>> But how do you decide (in the general case, with the default JSON
>>>> renderer) which properties to escape() and which to send out
>>>> unescaped?
>>>>
>>>> And how do you tell the client (dont' say "configuration"
>>>> please ;-)
>>>> which ones are escaped?
>>>>
>>>> -Bertrand
>>>>
>>>
>>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
Hi,
Well, I think that the need for escaping chars exist because json is itself
just text, and if a proeprty value contains a lot of """" here and there for
instance, it will bork the value and also the client-side javascript
parsing.
This is normally no problem for simple values, when using Sling as a
database of sorts, but as part of my Sling resource editor, I'd liek to be
able to insert HTML code inside a node, which contains a lot of quotes, and
possibly even JavaScript.
So, that's why.
Cheers,
PS
On Jan 22, 2008 2:56 PM, David Nuescheler <da...@day.com> wrote:
> hi guys,
>
> i am still somewhat confused why we are looking into the whole
> escaping issue. was there an actual issue at hand?
>
> so far i have not experienced any issue with the current "escaping"
> and i really would stay away from something like url escaping... i simply
> don't see a need.
> am i mistaken?
>
> btw: i am happy to remove the quotes from names that don't need
> the quotes.
>
> regards,
> david
>
>
> On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
> > Ahem. :) I kind of assumed that the "sling:resourceType" property was
> magic,
> > and anything inside it would something that could be rendered in a
> browser.
> > Maybe not.
> >
> > I think that one of the problems in learning Sling is that it seems to
> be
> > infinitely configurable, so that you can add renderers for things on the
> > fly, et.c. But if I say it this was; If there is some kind of basic type
> in
> > Sling for content to be consumed in a browser, then that could
> reasonably be
> > decalured to be of type urlencoded String. Would that be OK.
> >
> > Also, for my current project (Bunkai editor for Sling), I don't really
> need
> > the content int he json structure, I only need the hierarchical
> structure,
> > in array format already described, and some unique id/name that I can
> use
> > later, when a treenode (in Dojo) is sleected, to get the actual content.
> >
> > Cheers,
> > PS
> >
> > On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <bd...@apache.org>
> > wrote:
> >
> > > On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com> wrote:
> > >
> > > > ...The 'meaning' of a property value is application domain specific
> > > anyway, so
> > > > I think we can choose any encoding type which is reasonably simple,
> as
> > > long
> > > > as it is documented clearly....
> > >
> > > But how do you decide (in the general case, with the default JSON
> > > renderer) which properties to escape() and which to send out
> > > unescaped?
> > >
> > > And how do you tell the client (dont' say "configuration" please ;-)
> > > which ones are escaped?
> > >
> > > -Bertrand
> > >
> >
>
Re: Default JSON format (was: How does one build Sling?)
Posted by David Nuescheler <da...@day.com>.
hi guys,
i am still somewhat confused why we are looking into the whole
escaping issue. was there an actual issue at hand?
so far i have not experienced any issue with the current "escaping"
and i really would stay away from something like url escaping... i simply
don't see a need.
am i mistaken?
btw: i am happy to remove the quotes from names that don't need
the quotes.
regards,
david
On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
> Ahem. :) I kind of assumed that the "sling:resourceType" property was magic,
> and anything inside it would something that could be rendered in a browser.
> Maybe not.
>
> I think that one of the problems in learning Sling is that it seems to be
> infinitely configurable, so that you can add renderers for things on the
> fly, et.c. But if I say it this was; If there is some kind of basic type in
> Sling for content to be consumed in a browser, then that could reasonably be
> decalured to be of type urlencoded String. Would that be OK.
>
> Also, for my current project (Bunkai editor for Sling), I don't really need
> the content int he json structure, I only need the hierarchical structure,
> in array format already described, and some unique id/name that I can use
> later, when a treenode (in Dojo) is sleected, to get the actual content.
>
> Cheers,
> PS
>
> On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
> > On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com> wrote:
> >
> > > ...The 'meaning' of a property value is application domain specific
> > anyway, so
> > > I think we can choose any encoding type which is reasonably simple, as
> > long
> > > as it is documented clearly....
> >
> > But how do you decide (in the general case, with the default JSON
> > renderer) which properties to escape() and which to send out
> > unescaped?
> >
> > And how do you tell the client (dont' say "configuration" please ;-)
> > which ones are escaped?
> >
> > -Bertrand
> >
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
Ahem. :) I kind of assumed that the "sling:resourceType" property was magic,
and anything inside it would something that could be rendered in a browser.
Maybe not.
I think that one of the problems in learning Sling is that it seems to be
infinitely configurable, so that you can add renderers for things on the
fly, et.c. But if I say it this was; If there is some kind of basic type in
Sling for content to be consumed in a browser, then that could reasonably be
decalured to be of type urlencoded String. Would that be OK.
Also, for my current project (Bunkai editor for Sling), I don't really need
the content int he json structure, I only need the hierarchical structure,
in array format already described, and some unique id/name that I can use
later, when a treenode (in Dojo) is sleected, to get the actual content.
Cheers,
PS
On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com> wrote:
>
> > ...The 'meaning' of a property value is application domain specific
> anyway, so
> > I think we can choose any encoding type which is reasonably simple, as
> long
> > as it is documented clearly....
>
> But how do you decide (in the general case, with the default JSON
> renderer) which properties to escape() and which to send out
> unescaped?
>
> And how do you tell the client (dont' say "configuration" please ;-)
> which ones are escaped?
>
> -Bertrand
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 11:53 AM, Peter Svensson <ps...@gmail.com> wrote:
> ...The 'meaning' of a property value is application domain specific anyway, so
> I think we can choose any encoding type which is reasonably simple, as long
> as it is documented clearly....
But how do you decide (in the general case, with the default JSON
renderer) which properties to escape() and which to send out
unescaped?
And how do you tell the client (dont' say "configuration" please ;-)
which ones are escaped?
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
And, yes, that's also what I'm thinking. It doesn't matter in json what the
contents of a string is, as long as it doesn't mess with the json structure
itself (which it can do now).
The 'meaning' of a property value is application domain specific anyway, so
I think we can choose any encoding type which is reasonably simple, as long
as it is documented clearly.
Cheers,
PS
On Jan 22, 2008 11:46 AM, David Nuescheler <da...@day.com> wrote:
> > > ...I personally believe that we should support a simple way for people
> to
> > > get to different views of the same json (like the DOJO tree
> structure).
> > > Now, I am not sure if we need to do that on the server side...
> > That can be done on the client, sure, but I think we should support
> > some useful cases on the server side.
> it depends on the client lib that you are using. some js client libs
> require urls to pull their data from, then we are locked into doing that
> on the server.
>
> > > ... from a url perspective something like ...
> > >
> > > /mynode.all.0.json
> > > /mynode.all.1.json
> > >
> > > ... or ...
> > >
> > > /mynode.dojotree.infinity.json
> > >
> > > could do the trick...
> > Agreed, the convention would then be to use the last selector
> > (0,1,infinity) for the recursion level, and the selector before that
> > for the JSON "flavor".
> given our current resolving i think we actually can leave this open.
> right?
>
> if i assume that i have the following setup.
>
> .../json.servlet (which handles everything that is not mapped)
> .../dojotree/json.esp (woudl deal with the server sided conversion)
>
> wouldn't that be natural? it is then up to the dojotree/json.esp to worry
> about the additional parameters... right?
>
> > Currently the default renderers are hardcoded in the
> > launchpad-servlets module, but we'll need to make them pluggable at
> > some point anyway, so implementing what you suggest shouldn't be a
> > problem.
> i see ;)
>
> regards,
> david
>
Re: Default JSON format (was: How does one build Sling?)
Posted by David Nuescheler <da...@day.com>.
> > ...I personally believe that we should support a simple way for people to
> > get to different views of the same json (like the DOJO tree structure).
> > Now, I am not sure if we need to do that on the server side...
> That can be done on the client, sure, but I think we should support
> some useful cases on the server side.
it depends on the client lib that you are using. some js client libs
require urls to pull their data from, then we are locked into doing that
on the server.
> > ... from a url perspective something like ...
> >
> > /mynode.all.0.json
> > /mynode.all.1.json
> >
> > ... or ...
> >
> > /mynode.dojotree.infinity.json
> >
> > could do the trick...
> Agreed, the convention would then be to use the last selector
> (0,1,infinity) for the recursion level, and the selector before that
> for the JSON "flavor".
given our current resolving i think we actually can leave this open.
right?
if i assume that i have the following setup.
.../json.servlet (which handles everything that is not mapped)
.../dojotree/json.esp (woudl deal with the server sided conversion)
wouldn't that be natural? it is then up to the dojotree/json.esp to worry
about the additional parameters... right?
> Currently the default renderers are hardcoded in the
> launchpad-servlets module, but we'll need to make them pluggable at
> some point anyway, so implementing what you suggest shouldn't be a
> problem.
i see ;)
regards,
david
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 11:04 AM, David Nuescheler <da...@day.com> wrote:
> ...I personally believe that we should support a simple way for people to
> get to different views of the same json (like the DOJO tree structure).
> Now, I am not sure if we need to do that on the server side...
That can be done on the client, sure, but I think we should support
some useful cases on the server side.
> ... from a url perspective something like ...
>
> /mynode.all.0.json
> /mynode.all.1.json
>
> ... or ...
>
> /mynode.dojotree.infinity.json
>
> could do the trick...
Agreed, the convention would then be to use the last selector
(0,1,infinity) for the recursion level, and the selector before that
for the JSON "flavor".
Currently the default renderers are hardcoded in the
launchpad-servlets module, but we'll need to make them pluggable at
some point anyway, so implementing what you suggest shouldn't be a
problem.
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
Hi,
I don't know enough about system particulars to recommend what to do, but
from a 'user' perspective, it would have been great to be able to have
several kinds of json renderings, to provide for different libraries. I bet
that YUI and Ext have different choices, for instance.
My first idea, was to write a short esp script, which accessed the node info
and which generated a structure based on that. It would be shorter that the
requisite Java render by (probably) an order of magnitudes, and would be
very easy to extend or modify.
But that is where I got stuck, since I don't understand Sling so well yet.
It should be workable, but since things are in flux right now, I get easily
confused :)
Maybe I should try to generate my own Sling start.jar from the svn i checked
out last night, and see if I can insert an esp script at some point.
Cheers,
PS
On Jan 22, 2008 11:04 AM, David Nuescheler <da...@day.com> wrote:
> hi guys,
>
> On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > DOJOTree vs. generic json tree
>
> You are bringing up very good point.
>
> First of all I think the default serialization should not include
> "jcr:primaryType" (and other system props) and I still think that this
> is something that we did not get around to fix for ujax.
>
> I reported an Issue for that:
> https://issues.apache.org/jira/browse/SLING-182
>
> I personally believe that we should support a simple way for people to
> get to different views of the same json (like the DOJO tree structure).
> Now, I am not sure if we need to do that on the server side, maybe Peter
> can shed some light on this: If you would acquire the data through
> something like ujax.getContent() and then manipulate the object tree
> on the client side, can you then supply the data for the DOJO tree
> after that from a client side method or does the DOJO tree strictly
> require
> a URL?
>
> If it is easier to do things server sided then I would recommend to extend
> the "filter" mechanisms on the server side. Now looking at:
>
> /mynode.0.json
> /mynode.1.json
> /mynode.infinity.json
>
> ... from a url perspective something like ...
>
> /mynode.all.0.json
> /mynode.all.1.json
>
> ... or ...
>
> /mynode.dojotree.infinity.json
>
> could do the trick...
>
> thoughts?
>
> regards,
> david
>
> On 1/22/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > Hi,
> >
> > (renaming the thread to attract attention of our JSON folks)
> >
> > On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > > ...The json that would be nice to have is something like this;
> > >
> > > {
> > > label: 'name',
> > > identifier: 'name',
> > > items:
> > > [
> > > { name:'Fruit', type:'category'},
> > > { name:'Cinammon', type: 'category',
> > > children:
> > > [
> > > { name:'Cinammon Roll', type:'poptart' },
> > > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > > { name:'French Toast', type:'poptart' }
> > > ]
> > > },
> > > { name:'Chocolate', type: 'category'}
> > > ]
> > > }
> > >
> > > Where the only important stuff here is that child nodes should be put
> in a
> > > separate array [], not as an object to the parent node, like this;
> >
> > ...(snipped current format)
> >
> > Ok, so basically you'd like the child nodes to be in an array named
> "children".
> >
> > I know others on this list have more javascript experience than me,
> > what do people think?
> >
> > > ....Also, I have difficulties understanding what to do with the
> > >
> > > "testing":
> > > {"jcr:primaryType":"nt:unstructured",
> > >
> > > part, since I would somehow like it to be like this;
> > >
> > > children:
> > > [
> > > {
> > > title: 'testing',
> > > jcr_primaryType: 'nt:unstructured',
> > > children:
> > > [
> > > { title:"test2", sling_resourceType:
> > > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default
> text of
> > > the test node"},
> > > ....
> > > ]
> > > }
> > > ]
> > >
> > > Hmm. I really think that this would be the correct translation, now
> that
> > > I've printed it out. The problem was in choosing how to remove the
> current
> > > "name: {}" structure to move the name into the object (where it is
> anyway),
> > > like children: [{title: name....}]...
> >
> > Ok, I agree that the above is more immediately understandable than the
> > current format.
> >
> > The downside, iiuc, is that if forces the use of ".children." to
> > access children...well, not sure if that's a downside, let's hear what
> > other javascript aficionados think!
> >
> > > ...Note that children is just a convenient name, and doesn't mean
> anything
> > > magic. Also, I would feel very much more comfortable not having quotes
> > > around property names. I understand that they're there to escape the
> ':' ,
> > > which are very magic in js and separates property names from values,
> > > therefore I replaced them with underscores....
> >
> > IIUC, the goal with removing the quotes is only to make the JSON look
> > nicer, is that right?
> >
> > The problem with transforming sling:resourceType to sling_resourceType
> > in JSON is the possible confusion in documentation and in people's
> > minds...I don't like that too much.
> >
> > As you indicate, making other JSON renditions pluggable would be easy,
> > but I think we should be able to agree on a good enough default
> > format.
> >
> > -Bertrand
> >
>
Re: Default JSON format (was: How does one build Sling?)
Posted by David Nuescheler <da...@day.com>.
hi guys,
On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> DOJOTree vs. generic json tree
You are bringing up very good point.
First of all I think the default serialization should not include
"jcr:primaryType" (and other system props) and I still think that this
is something that we did not get around to fix for ujax.
I reported an Issue for that:
https://issues.apache.org/jira/browse/SLING-182
I personally believe that we should support a simple way for people to
get to different views of the same json (like the DOJO tree structure).
Now, I am not sure if we need to do that on the server side, maybe Peter
can shed some light on this: If you would acquire the data through
something like ujax.getContent() and then manipulate the object tree
on the client side, can you then supply the data for the DOJO tree
after that from a client side method or does the DOJO tree strictly require
a URL?
If it is easier to do things server sided then I would recommend to extend
the "filter" mechanisms on the server side. Now looking at:
/mynode.0.json
/mynode.1.json
/mynode.infinity.json
... from a url perspective something like ...
/mynode.all.0.json
/mynode.all.1.json
... or ...
/mynode.dojotree.infinity.json
could do the trick...
thoughts?
regards,
david
On 1/22/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> (renaming the thread to attract attention of our JSON folks)
>
> On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > ...The json that would be nice to have is something like this;
> >
> > {
> > label: 'name',
> > identifier: 'name',
> > items:
> > [
> > { name:'Fruit', type:'category'},
> > { name:'Cinammon', type: 'category',
> > children:
> > [
> > { name:'Cinammon Roll', type:'poptart' },
> > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > { name:'French Toast', type:'poptart' }
> > ]
> > },
> > { name:'Chocolate', type: 'category'}
> > ]
> > }
> >
> > Where the only important stuff here is that child nodes should be put in a
> > separate array [], not as an object to the parent node, like this;
>
> ...(snipped current format)
>
> Ok, so basically you'd like the child nodes to be in an array named "children".
>
> I know others on this list have more javascript experience than me,
> what do people think?
>
> > ....Also, I have difficulties understanding what to do with the
> >
> > "testing":
> > {"jcr:primaryType":"nt:unstructured",
> >
> > part, since I would somehow like it to be like this;
> >
> > children:
> > [
> > {
> > title: 'testing',
> > jcr_primaryType: 'nt:unstructured',
> > children:
> > [
> > { title:"test2", sling_resourceType:
> > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default text of
> > the test node"},
> > ....
> > ]
> > }
> > ]
> >
> > Hmm. I really think that this would be the correct translation, now that
> > I've printed it out. The problem was in choosing how to remove the current
> > "name: {}" structure to move the name into the object (where it is anyway),
> > like children: [{title: name....}]...
>
> Ok, I agree that the above is more immediately understandable than the
> current format.
>
> The downside, iiuc, is that if forces the use of ".children." to
> access children...well, not sure if that's a downside, let's hear what
> other javascript aficionados think!
>
> > ...Note that children is just a convenient name, and doesn't mean anything
> > magic. Also, I would feel very much more comfortable not having quotes
> > around property names. I understand that they're there to escape the ':' ,
> > which are very magic in js and separates property names from values,
> > therefore I replaced them with underscores....
>
> IIUC, the goal with removing the quotes is only to make the JSON look
> nicer, is that right?
>
> The problem with transforming sling:resourceType to sling_resourceType
> in JSON is the possible confusion in documentation and in people's
> minds...I don't like that too much.
>
> As you indicate, making other JSON renditions pluggable would be easy,
> but I think we should be able to agree on a good enough default
> format.
>
> -Bertrand
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 11:04 AM, Peter Svensson <ps...@gmail.com> wrote:
> ...My reference page has been this;
> http://www.json.org/js.html, and also teh RFC;
> http://www.ietf.org/rfc/rfc4627.txt?number=4627 When reading that more
> closely, they (or actually he - it's Douglas Crockford :) do actually
> mention escaping of characters;...
Ok.
> ...However, the pragmatic approach in dealing with shady string is really to
> escape them, so that for instance the text;
>
> foobar; "yohoo!" $bar
>
> becomes
>
> foobar%3B%20%22yohoo%21%22%20%24bar...
But in that case the client and server have to agree on which values
are escaped, right?
Is there a standard way in JSON to tell he decoder "pass this value
through unescape() first?".
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
Hmm. Good point. My reference page has been this;
http://www.json.org/js.html, and also teh RFC;
http://www.ietf.org/rfc/rfc4627.txt?number=4627 When reading that more
closely, they (or actually he - it's Douglas Crockford :) do actually
mention escaping of characters;
---
2.5. Strings
The representation of strings is similar to conventions used in the C
family of programming languages. A string begins and ends with
quotation marks. All Unicode characters may be placed within the
quotation marks except for the characters that must be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).
Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+0000 through U+FFFF), then it may be
represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point. The hexadecimal letters A though
F can be upper or lowercase. So, for example, a string containing
only a single reverse solidus character may be represented as
"\u005C".
Alternatively, there are two-character sequence escape
representations of some popular characters. So, for example, a
string containing only a single reverse solidus character may be
represented more compactly as "\\".
To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a twelve-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as
"\uD834\uDD1E".
---
However, the pragmatic approach in dealing with shady string is really to
escape them, so that for instance the text;
foobar; "yohoo!" $bar
becomes
foobar%3B%20%22yohoo%21%22%20%24bar
(I used the very good test page
http://www.the-art-of-web.com/javascript/escape/ to try different approaches
out),
since it's very easy in js to unescape string, thus converting them into
original values.
Cheers,
PS
On Jan 22, 2008 10:40 AM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Jan 22, 2008 10:31 AM, Peter Svensson <ps...@gmail.com> wrote:
> > ...I personally prefer to just have object within objects. it's
> > just that I have to translate the thing to a format that Dojo's Tree
> widget
> > can consume....
>
> Ok, so IIUC Sling's default JSON format is ok, but you'd need a
> different dojo-friendly format in addition to it?
>
> If yes that's easy to implement, we could do that with a selector
> routed to a specific JSON rendering servlet, i.e. URLs ending in
> ".dojo.json" would be served with a different format than the stock
> .json.
>
> > ....maybe it would be a good idea to have an escaping strategy for
> > content inside the json structure. This can be non-trivial, since the
> > content can contain client-side js which uses escaping itself, and so
> on.
> >
> > The most 'safe' approach would be to urlencode all properties which
> contain
> > this kind of information (i.e. can be showed in the browser), since it
> is
> > trivial to revert it back, and it is supposed to be consumed by
> javascript
> > anyway....
>
> Sounds interesting - is that a JSON standard way of encoding
> properties? Do you have references to that?
>
> -Bertrand
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 22, 2008 10:31 AM, Peter Svensson <ps...@gmail.com> wrote:
> ...I personally prefer to just have object within objects. it's
> just that I have to translate the thing to a format that Dojo's Tree widget
> can consume....
Ok, so IIUC Sling's default JSON format is ok, but you'd need a
different dojo-friendly format in addition to it?
If yes that's easy to implement, we could do that with a selector
routed to a specific JSON rendering servlet, i.e. URLs ending in
".dojo.json" would be served with a different format than the stock
.json.
> ....maybe it would be a good idea to have an escaping strategy for
> content inside the json structure. This can be non-trivial, since the
> content can contain client-side js which uses escaping itself, and so on.
>
> The most 'safe' approach would be to urlencode all properties which contain
> this kind of information (i.e. can be showed in the browser), since it is
> trivial to revert it back, and it is supposed to be consumed by javascript
> anyway....
Sounds interesting - is that a JSON standard way of encoding
properties? Do you have references to that?
-Bertrand
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
Yes, actually, I personally prefer to just have object within objects. it's
just that I have to translate the thing to a format that Dojo's Tree widget
can consume. So in that respect it makes more sense to translate it locally,
instead of changing the output from the server. Maybe to be able to have two
different json formats, one which was dojo pluggable?
Another thing that I've noticed is that when I pasted a workable dojo editor
(which is in this comment somewhere) html page into Sling, (it worked very
well), when I get the generated json, the quotes inside the page is not
escaped, which leads to a really illegal json structure, which looks a bit
like thsi;
{
...
"d1":
{ "title":"d1","sling:resourceType":"<!DOCTYPE HTML
PUBLIC \"-//W3C//DTD HTML 4.01//EN\"\r\n \"
http://www.w3.org/TR/html4/strict.dtd\">\r\n<html>\r\n<head>\r\n<meta
http-equiv=\"Content-Type\" content=\"text/html;
charset=UTF-8\">\r\n<title>Editor Demo<\/title>\r\n .......
...
}
Note that the property value of the "sling:resoruceType" is double quoted
"", but inside those quotes, there are string like 'content="text/html"',
et.c. So maybe it would be a good idea to have an escaping strategy for
content inside the json structure. This can be non-trivial, since the
content can contain client-side js which uses escaping itself, and so on.
The most 'safe' approach would be to urlencode all properties which contain
this kind of information (i.e. can be showed in the browser), since it is
trivial to revert it back, and it is supposed to be consumed by javascript
anyway. What do people think?
Cheers,
PS
Cheers,
PS
On Jan 22, 2008 10:21 AM, Philipp Koch <ph...@day.com> wrote:
> hi,
> i like the current "json node export" format since it seems to me more
> natural (in respect to jcr).
>
> regards,
> philipp
>
> On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
> > On Jan 22, 2008 10:08 AM, Bertrand Delacretaz <bd...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > (renaming the thread to attract attention of our JSON folks)
> > >
> >
> > Good idea. Thanks.
> >
> >
> > >
> > > On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > > > ...The json that would be nice to have is something like this;
> > > >
> > > > {
> > > > label: 'name',
> > > > identifier: 'name',
> > > > items:
> > > > [
> > > > { name:'Fruit', type:'category'},
> > > > { name:'Cinammon', type: 'category',
> > > > children:
> > > > [
> > > > { name:'Cinammon Roll', type:'poptart' },
> > > > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > > > { name:'French Toast', type:'poptart' }
> > > > ]
> > > > },
> > > > { name:'Chocolate', type: 'category'}
> > > > ]
> > > > }
> > > >
> > > > Where the only important stuff here is that child nodes should be
> put in
> > > a
> > > > separate array [], not as an object to the parent node, like this;
> > >
> > > ...(snipped current format)
> > >
> > > Ok, so basically you'd like the child nodes to be in an array named
> > > "children".
> > >
> > > I know others on this list have more javascript experience than me,
> > > what do people think?
> > >
> > > > ....Also, I have difficulties understanding what to do with the
> > > >
> > > > "testing":
> > > > {"jcr:primaryType":"nt:unstructured",
> > > >
> > > > part, since I would somehow like it to be like this;
> > > >
> > > > children:
> > > > [
> > > > {
> > > > title: 'testing',
> > > > jcr_primaryType: 'nt:unstructured',
> > > > children:
> > > > [
> > > > { title:"test2", sling_resourceType:
> > > > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default
> > > text of
> > > > the test node"},
> > > > ....
> > > > ]
> > > > }
> > > > ]
> > > >
> > > > Hmm. I really think that this would be the correct translation, now
> that
> > > > I've printed it out. The problem was in choosing how to remove the
> > > current
> > > > "name: {}" structure to move the name into the object (where it is
> > > anyway),
> > > > like children: [{title: name....}]...
> > >
> > > Ok, I agree that the above is more immediately understandable than the
> > > current format.
> > >
> > > The downside, iiuc, is that if forces the use of ".children." to
> > > access children...well, not sure if that's a downside, let's hear what
> > > other javascript aficionados think!
> > >
> >
> > Well, I think its OK. Children would refer to an array of object, and
> each
> > object could have another children property which had an array as value,
> so
> > I don't think it would be a problem (from a purely js perspective)
> >
> >
> > >
> > > > ...Note that children is just a convenient name, and doesn't mean
> > > anything
> > > > magic. Also, I would feel very much more comfortable not having
> quotes
> > > > around property names. I understand that they're there to escape the
> ':'
> > > ,
> > > > which are very magic in js and separates property names from values,
> > > > therefore I replaced them with underscores....
> > >
> > > IIUC, the goal with removing the quotes is only to make the JSON look
> > > nicer, is that right?
> > >
> >
> > Argh! You got me there :). I'm just used to not having any quotes on
> > property names, but I'd have to google to know if there's any
> difference, so
> > for now, yes only to look nice - and I agree that it's not a good thing
> to
> > have the name change, depending on platform.
> >
> >
> > >
> > > The problem with transforming sling:resourceType to sling_resourceType
> > > in JSON is the possible confusion in documentation and in people's
> > > minds...I don't like that too much.
> > >
> > > As you indicate, making other JSON renditions pluggable would be easy,
> > > but I think we should be able to agree on a good enough default
> > > format.
> > >
> > > -Bertrand
> > >
> >
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Philipp Koch <ph...@day.com>.
hi,
i like the current "json node export" format since it seems to me more
natural (in respect to jcr).
regards,
philipp
On 1/22/08, Peter Svensson <ps...@gmail.com> wrote:
> On Jan 22, 2008 10:08 AM, Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
> > Hi,
> >
> > (renaming the thread to attract attention of our JSON folks)
> >
>
> Good idea. Thanks.
>
>
> >
> > On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > > ...The json that would be nice to have is something like this;
> > >
> > > {
> > > label: 'name',
> > > identifier: 'name',
> > > items:
> > > [
> > > { name:'Fruit', type:'category'},
> > > { name:'Cinammon', type: 'category',
> > > children:
> > > [
> > > { name:'Cinammon Roll', type:'poptart' },
> > > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > > { name:'French Toast', type:'poptart' }
> > > ]
> > > },
> > > { name:'Chocolate', type: 'category'}
> > > ]
> > > }
> > >
> > > Where the only important stuff here is that child nodes should be put in
> > a
> > > separate array [], not as an object to the parent node, like this;
> >
> > ...(snipped current format)
> >
> > Ok, so basically you'd like the child nodes to be in an array named
> > "children".
> >
> > I know others on this list have more javascript experience than me,
> > what do people think?
> >
> > > ....Also, I have difficulties understanding what to do with the
> > >
> > > "testing":
> > > {"jcr:primaryType":"nt:unstructured",
> > >
> > > part, since I would somehow like it to be like this;
> > >
> > > children:
> > > [
> > > {
> > > title: 'testing',
> > > jcr_primaryType: 'nt:unstructured',
> > > children:
> > > [
> > > { title:"test2", sling_resourceType:
> > > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default
> > text of
> > > the test node"},
> > > ....
> > > ]
> > > }
> > > ]
> > >
> > > Hmm. I really think that this would be the correct translation, now that
> > > I've printed it out. The problem was in choosing how to remove the
> > current
> > > "name: {}" structure to move the name into the object (where it is
> > anyway),
> > > like children: [{title: name....}]...
> >
> > Ok, I agree that the above is more immediately understandable than the
> > current format.
> >
> > The downside, iiuc, is that if forces the use of ".children." to
> > access children...well, not sure if that's a downside, let's hear what
> > other javascript aficionados think!
> >
>
> Well, I think its OK. Children would refer to an array of object, and each
> object could have another children property which had an array as value, so
> I don't think it would be a problem (from a purely js perspective)
>
>
> >
> > > ...Note that children is just a convenient name, and doesn't mean
> > anything
> > > magic. Also, I would feel very much more comfortable not having quotes
> > > around property names. I understand that they're there to escape the ':'
> > ,
> > > which are very magic in js and separates property names from values,
> > > therefore I replaced them with underscores....
> >
> > IIUC, the goal with removing the quotes is only to make the JSON look
> > nicer, is that right?
> >
>
> Argh! You got me there :). I'm just used to not having any quotes on
> property names, but I'd have to google to know if there's any difference, so
> for now, yes only to look nice - and I agree that it's not a good thing to
> have the name change, depending on platform.
>
>
> >
> > The problem with transforming sling:resourceType to sling_resourceType
> > in JSON is the possible confusion in documentation and in people's
> > minds...I don't like that too much.
> >
> > As you indicate, making other JSON renditions pluggable would be easy,
> > but I think we should be able to agree on a good enough default
> > format.
> >
> > -Bertrand
> >
>
Re: Default JSON format (was: How does one build Sling?)
Posted by Peter Svensson <ps...@gmail.com>.
On Jan 22, 2008 10:08 AM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi,
>
> (renaming the thread to attract attention of our JSON folks)
>
Good idea. Thanks.
>
> On Jan 22, 2008 9:47 AM, Peter Svensson <ps...@gmail.com> wrote:
> > ...The json that would be nice to have is something like this;
> >
> > {
> > label: 'name',
> > identifier: 'name',
> > items:
> > [
> > { name:'Fruit', type:'category'},
> > { name:'Cinammon', type: 'category',
> > children:
> > [
> > { name:'Cinammon Roll', type:'poptart' },
> > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > { name:'French Toast', type:'poptart' }
> > ]
> > },
> > { name:'Chocolate', type: 'category'}
> > ]
> > }
> >
> > Where the only important stuff here is that child nodes should be put in
> a
> > separate array [], not as an object to the parent node, like this;
>
> ...(snipped current format)
>
> Ok, so basically you'd like the child nodes to be in an array named
> "children".
>
> I know others on this list have more javascript experience than me,
> what do people think?
>
> > ....Also, I have difficulties understanding what to do with the
> >
> > "testing":
> > {"jcr:primaryType":"nt:unstructured",
> >
> > part, since I would somehow like it to be like this;
> >
> > children:
> > [
> > {
> > title: 'testing',
> > jcr_primaryType: 'nt:unstructured',
> > children:
> > [
> > { title:"test2", sling_resourceType:
> > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default
> text of
> > the test node"},
> > ....
> > ]
> > }
> > ]
> >
> > Hmm. I really think that this would be the correct translation, now that
> > I've printed it out. The problem was in choosing how to remove the
> current
> > "name: {}" structure to move the name into the object (where it is
> anyway),
> > like children: [{title: name....}]...
>
> Ok, I agree that the above is more immediately understandable than the
> current format.
>
> The downside, iiuc, is that if forces the use of ".children." to
> access children...well, not sure if that's a downside, let's hear what
> other javascript aficionados think!
>
Well, I think its OK. Children would refer to an array of object, and each
object could have another children property which had an array as value, so
I don't think it would be a problem (from a purely js perspective)
>
> > ...Note that children is just a convenient name, and doesn't mean
> anything
> > magic. Also, I would feel very much more comfortable not having quotes
> > around property names. I understand that they're there to escape the ':'
> ,
> > which are very magic in js and separates property names from values,
> > therefore I replaced them with underscores....
>
> IIUC, the goal with removing the quotes is only to make the JSON look
> nicer, is that right?
>
Argh! You got me there :). I'm just used to not having any quotes on
property names, but I'd have to google to know if there's any difference, so
for now, yes only to look nice - and I agree that it's not a good thing to
have the name change, depending on platform.
>
> The problem with transforming sling:resourceType to sling_resourceType
> in JSON is the possible confusion in documentation and in people's
> minds...I don't like that too much.
>
> As you indicate, making other JSON renditions pluggable would be easy,
> but I think we should be able to agree on a good enough default
> format.
>
> -Bertrand
>