You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Buchmann <da...@liip.ch> on 2012/03/07 20:35:14 UTC
jsop and property / node with same name
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
while implementing the jackalope php jsop client for the jackrabbit
backend, i stumbled over a problem with the json returned when a
property and a child node have the same name:
the repository is something like this:
<test toast="bar">
<toast/>
</test>
to create it, i do
Session s = repository.login(credentials,workspace);
Node n = s.getRootNode().addNode("test");
n.setProperty("toast", "bar");
n.addNode("toast");
s.save();
now the json returned for /test looks like this:
{"toast":"bar",":jcr:primaryType":"Name","jcr:primaryType":"nt:unstructured","toast":{}}
note: there is twice the key "toast". as far as i understand json, this
is not valid. the php function json_decode just overwrites the property
"toast" => "bar" with the node array "toast" => array(). javascript json
parsers tend to do the same.
is jackrabbit using a custom json parser that can handle same-name keys?
are there any plans to make this valid json?
or would the jcr spec forbid it? found nothing about it. when looking at
the xml representation, it sounds totally normal. when outputting i.e.
the path of the property and the node it looks strange.
thanks for input,
david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9XuHIACgkQqBnXnqWBgIss8QCgvUFwzFLURDtdRSXHrdrboCuu
AwIAoMNJSL0VwGfjxfDJy6c87k/5gbj5
=fe9h
-----END PGP SIGNATURE-----
Re: jsop and property / node with same name
Posted by David Buchmann <da...@liip.ch>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> or would the jcr spec forbid it? found nothing about it. when
>> looking at the xml representation, it sounds totally normal. when
>> outputting i.e. the path of the property and the node it looks
>> strange.
>
> as of jcr 2.0 properties and child nodes may share the same namespace
> [0].
ok, thanks stefan. so this is to be expected.
that leaves the question about the invalid json in jsop. any inputs on this?
> ...
> now the json returned for /test looks like this:
>
> {"toast":"bar",":jcr:primaryType":"Name","jcr:primaryType":"nt:unstructured","toast":{}}
>
>
> note: there is twice the key "toast". as far as i understand json, this
> is not valid. the php function json_decode just overwrites the property
> "toast" => "bar" with the node array "toast" => array(). javascript json
> parsers tend to do the same.
>
> is jackrabbit using a custom json parser that can handle same-name keys?
> are there any plans to make this valid json?
>> [0] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.4.2.2
>> Child Resolution
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9YhG4ACgkQqBnXnqWBgIun2QCgofJNqFReZ9d0w+isUoZkm/TO
M7AAnR3AccMtxD+bQryAhM+NUdmi57bZ
=PN3t
-----END PGP SIGNATURE-----
Re: jsop and property / node with same name
Posted by Stefan Guggisberg <st...@gmail.com>.
On Wed, Mar 7, 2012 at 8:35 PM, David Buchmann <da...@liip.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> while implementing the jackalope php jsop client for the jackrabbit
> backend, i stumbled over a problem with the json returned when a
> property and a child node have the same name:
>
> the repository is something like this:
> <test toast="bar">
> <toast/>
> </test>
>
> to create it, i do
>
> Session s = repository.login(credentials,workspace);
> Node n = s.getRootNode().addNode("test");
> n.setProperty("toast", "bar");
> n.addNode("toast");
> s.save();
>
> now the json returned for /test looks like this:
>
> {"toast":"bar",":jcr:primaryType":"Name","jcr:primaryType":"nt:unstructured","toast":{}}
>
>
> note: there is twice the key "toast". as far as i understand json, this
> is not valid. the php function json_decode just overwrites the property
> "toast" => "bar" with the node array "toast" => array(). javascript json
> parsers tend to do the same.
>
> is jackrabbit using a custom json parser that can handle same-name keys?
> are there any plans to make this valid json?
>
> or would the jcr spec forbid it? found nothing about it. when looking at
> the xml representation, it sounds totally normal. when outputting i.e.
> the path of the property and the node it looks strange.
as of jcr 2.0 properties and child nodes may share the same namespace [0].
cheers
stefan
[0] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.4.2.2
Child Resolution
>
> thanks for input,
> david
> - --
> Liip AG // Agile Web Development // T +41 26 422 25 11
> CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9XuHIACgkQqBnXnqWBgIss8QCgvUFwzFLURDtdRSXHrdrboCuu
> AwIAoMNJSL0VwGfjxfDJy6c87k/5gbj5
> =fe9h
> -----END PGP SIGNATURE-----
Re: jsop and property / node with same name
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-03-08 15:43, Angela Schreiber wrote:
> hi julian
>
>>> imo the same-name-property-node feature was a bad move in jsr 283
>>> and i don't see a particular value in having this feature.
>>> ...
>
>> I thought it was in JSR 170 already.
>
> noe... as far as i remember it was introduced with jsr 283 after
> quite some discussion. in JSR 170 this wasn't allowed as far as
> i know that's why there was originally no need to identify the
> item type from the webdav resource location.
>
> related discussions can be found in
> http://java.net/jira/browse/JSR_283-63
> http://java.net/jira/browse/JSR_283-25
> http://java.net/jira/browse/JSR_283-725
> ...
Indeed. Thanks for the clarification.
Re: jsop and property / node with same name
Posted by Angela Schreiber <an...@adobe.com>.
hi julian
>> imo the same-name-property-node feature was a bad move in jsr 283
>> and i don't see a particular value in having this feature.
>> ...
> I thought it was in JSR 170 already.
noe... as far as i remember it was introduced with jsr 283 after
quite some discussion. in JSR 170 this wasn't allowed as far as
i know that's why there was originally no need to identify the
item type from the webdav resource location.
related discussions can be found in
http://java.net/jira/browse/JSR_283-63
http://java.net/jira/browse/JSR_283-25
http://java.net/jira/browse/JSR_283-725
kind regards
angela
Re: jsop and property / node with same name
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-03-08 11:58, Angela Schreiber wrote:
> ...
> imo the same-name-property-node feature was a bad move in jsr 283
> and i don't see a particular value in having this feature.
> ...
I thought it was in JSR 170 already.
> some time ago i was chatting with julian about possibilities
> to distinguish properties and nodes in the jcr-remoting but
> we never really invested sufficient time to address this.
>
> as far as jsop is concerned i don't remember that we ever
> talked about this problematic. but you may come up with a
> suggestion on how to address this.
Essentially we need a well-defined mapping between a JCR node hierarchy
and JSON; right now there are edge case that IMHO break.
> without a having a closer look i can think of
> a - no supported at all (there is an repository descriptor for
> this called: OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED)
> -> fix jcr-server not to return this descriptor and not
> to allow for same-named node/property siblings
> b - supported by ignore the fact that it isn't valid json
> c - invent some extra marker for properties that have the same
> name as a sibling node.
> and there are for sure many other options if this really turns out
> to be a problem.
>
> b was for free, a was rather cheap. right now with all the
> jackrabbit3 effort i wouldn't invest a lot of time in c.
>
> but it's definitely worth to keep this in mind for later
> JSOP discussions in order not to forget to address this once
> we have a more formal and finalized protocol.
> ...
Indeed!
Re: jsop and property / node with same name
Posted by David Buchmann <da...@liip.ch>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
> as far as jsop is concerned i don't remember that we ever
> talked about this problematic. but you may come up with a
> suggestion on how to address this.
we could type the properties somehow. it felt weird when implementing
that the thing to identify if something is a node or a property is by
looking at if it has children.
we could have all nodes prepended a character that is not allowed at the
start of a jcr name, like we do for the property type meta information.
the smallest difference would be to have all child nodes start with : as
they afaik never have a type meta data.
> without a having a closer look i can think of
> a - no supported at all (there is an repository descriptor for
> this called: OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED)
> -> fix jcr-server not to return this descriptor and not
> to allow for same-named node/property siblings
> b - supported by ignore the fact that it isn't valid json
> c - invent some extra marker for properties that have the same
> name as a sibling node.
> and there are for sure many other options if this really turns out
> to be a problem.
i think a) making it optional is not very nice. b) is a problem for the
php implementation as we would need to implement our own json parser to
be able to parse broken json, which feels stupid.
if we would do c) as proposed above, would this have a chance of getting
accepted into jackrabbit 2.4 or 2.5? it would create an incompatibility
between the old and the new version if the client is older than the
server. (a new client could still accept the old format of child nodes
as well, but the old client would not expect the nodes to have a : in
front of them)
> but it's definitely worth to keep this in mind for later
> JSOP discussions in order not to forget to address this once
> we have a more formal and finalized protocol.
would be good yes.
cheers,
david
ps:
> imo the same-name-property-node feature was a bad move in jsr 283
> and i don't see a particular value in having this feature.
well, it is possible in xml and we have this import of xml documents...
but i guess we now have it so we do not need to argue if its good or bad :-/
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9Z/P0ACgkQqBnXnqWBgIuL3ACcC/BL8Nt9KKDdxHtnZkhHl0yG
iwEAoKZ31WzYlgTn+iKTT1wkUKjGYuaR
=7lWk
-----END PGP SIGNATURE-----
Re: jsop and property / node with same name
Posted by Angela Schreiber <an...@adobe.com>.
hi david
> note: there is twice the key "toast". as far as i understand json, this
> is not valid. the php function json_decode just overwrites the property
> "toast" => "bar" with the node array "toast" => array(). javascript json
> parsers tend to do the same.
>
> is jackrabbit using a custom json parser that can handle same-name keys?
jackrabbit has a custom json parser.
> are there any plans to make this valid json?
no... not at the moment as same name property and node are
not properly supported by the jcr remoting anyway (see also JCR-1616)
> or would the jcr spec forbid it? found nothing about it. when looking at
> the xml representation, it sounds totally normal. when outputting i.e.
> the path of the property and the node it looks strange.
>
> thanks for input,
imo the same-name-property-node feature was a bad move in jsr 283
and i don't see a particular value in having this feature.
some time ago i was chatting with julian about possibilities
to distinguish properties and nodes in the jcr-remoting but
we never really invested sufficient time to address this.
as far as jsop is concerned i don't remember that we ever
talked about this problematic. but you may come up with a
suggestion on how to address this.
without a having a closer look i can think of
a - no supported at all (there is an repository descriptor for
this called: OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED)
-> fix jcr-server not to return this descriptor and not
to allow for same-named node/property siblings
b - supported by ignore the fact that it isn't valid json
c - invent some extra marker for properties that have the same
name as a sibling node.
and there are for sure many other options if this really turns out
to be a problem.
b was for free, a was rather cheap. right now with all the
jackrabbit3 effort i wouldn't invest a lot of time in c.
but it's definitely worth to keep this in mind for later
JSOP discussions in order not to forget to address this once
we have a more formal and finalized protocol.
regards
angela
> david
> - --
> Liip AG // Agile Web Development // T +41 26 422 25 11
> CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9XuHIACgkQqBnXnqWBgIss8QCgvUFwzFLURDtdRSXHrdrboCuu
> AwIAoMNJSL0VwGfjxfDJy6c87k/5gbj5
> =fe9h
> -----END PGP SIGNATURE-----