<jer...@marzhillstudios.com> wrote: > why? You can do the same thing with both of them. What benefit do you get > from one over the other?
I suppose it would be easier for people that already works with XML on their application so they can store it directly in couchdb. I think the issue was already addressed here and the devs won't commit their time on 2 different type of storage IIRC, which is fine with me as I prefer json :)
I've settled on the TIBCO General Interface IDE to develop a concept.
If both XML and JSON were available,
then couchDB would be a very good match to use with GI.
Dave
On Feb 15, 3:39 pm, "Jeremy Wall" <jer...@marzhillstudios.com> wrote:
> <jer...@marzhillstudios.com> wrote:
> > why? You can do the same thing with both of them. What benefit do you get
> > from one over the other?
> I suppose it would be easier for people that already works with XML on
> their application so they can store it directly in couchdb.
> I think the issue was already addressed here and the devs won't commit
> their time on 2 different type of storage IIRC, which is fine with me
> as I prefer json :)
Hi,
On Feb 16, 1:55 am, dave37 <merd...@homenetnw.net> wrote:
> Hi Patrick.
> Wasn't XML the data type for the first few versions of couchDB? So,
> most of the coding should already be there.
yeah, but we threw it all away :) But seriously. CouchDB uses the
Erlang-
representation of JSON internally now, so just 'enabling the XML-code'
won't work.
> > Maybe any created db would have to be restricted to either JSON or
> XML: that might simplify things.
> JSON is also my preference but XML sometimes might be better to use
> for content.
We suggest using a transparent XML-JSON converter in the storage layer
of your application.
> On Feb 15, 4:24 pm, "Patrick Aljord" <patc...@gmail.com> wrote:
> > On Sat, Feb 16, 2008 at 12:39 AM, Jeremy Wall
> > <jer...@marzhillstudios.com> wrote:
> > > why? You can do the same thing with both of them. What benefit do you get
> > > from one over the other?
> > I suppose it would be easier for people that already works with XML on
> > their application so they can store it directly in couchdb.
> > I think the issue was already addressed here and the devs won't commit
> > their time on 2 different type of storage IIRC, which is fine with me
> > as I prefer json :)
In view of your reply I guess that a "transparent XML-JSON converter"
is the way to go.
Can anyone point me to a good, fast, bi-directional, open-source XML-
JSON converter?
One written in JS or erlang would be best.
By the way, I sent a few hours in the erlang tutorial a few day ago.
Its pattern-matching approach
is really a different way of programming compared to C++ or
javascript! But it makes sense in today's world of quad-cores ( even
8-cores now).
Maybe in a few weeks I'll be able to make the mind-set change and be
able to think in the erlang lanuage.
Thanks to all,
Dave
On Feb 16, 9:11 am, Jan L <JanLehna...@googlemail.com> wrote:
> Hi,
> On Feb 16, 1:55 am, dave37 <merd...@homenetnw.net> wrote:
> > Hi Patrick.
> > Wasn't XML the data type for the first few versions of couchDB? So,
> > most of the coding should already be there.
> yeah, but we threw it all away :) But seriously. CouchDB uses the
> Erlang-
> representation of JSON internally now, so just 'enabling the XML-code'
> won't work.
> > > Maybe any created db would have to be restricted to either JSON or
> > XML: that might simplify things.
> > JSON is also my preference but XML sometimes might be better to use
> > for content.
> We suggest using a transparent XML-JSON converter in the storage layer
> of your application.
> > Dave
> > On Feb 15, 4:24 pm, "Patrick Aljord" <patc...@gmail.com> wrote:
> > > On Sat, Feb 16, 2008 at 12:39 AM, Jeremy Wall
> > > <jer...@marzhillstudios.com> wrote:
> > > > why? You can do the same thing with both of them. What benefit do you get
> > > > from one over the other?
> > > I suppose it would be easier for people that already works with XML on
> > > their application so they can store it directly in couchdb.
> > > I think the issue was already addressed here and the devs won't commit
> > > their time on 2 different type of storage IIRC, which is fine with me
> > > as I prefer json :)
So, it appears there will be even more demand for DBs that can store
XML
as a native format.
I'm starting to work with OWL and GI. Both use XML.
Those working in the semantic web tend to use XML.
Many on the cutting-edge of AI use XML.
Does it make sense to confine couchDB to just JSON?
Why would you want to put even the minor obstacle of
XML2JSON translation in the way of all these potential
users of couchDB?
By the way I cannot find a truly bi-directional translator;
XML and JSON are not perfectly compatible in what
they can handle.
Now for a little PR. I really do appreciate all the work ya'll are
doing. IMHO, couchDB is a great, timely concept.
Please reconsider including XML, even if it is put on a low priority.
> Now for a little PR. I really do appreciate all the work ya'll are > doing. IMHO, couchDB is a great, timely concept. > Please reconsider including XML, even if it is put on a low priority.
We'll probably enable E4X[1] in the Javascript view server to allow people to easily access XML content inside JSON documents. And if you're not using Javascript views, you can just use the XML libs that come with the language in use (such as Pthon or Ruby). No need to bake XML support into Couch itself.
> So, it appears there will be even more demand for DBs that can store
> XML
> as a native format.
> I'm starting to work with OWL and GI. Both use XML.
> Those working in the semantic web tend to use XML.
> Many on the cutting-edge of AI use XML.
> Does it make sense to confine couchDB to just JSON?
> Why would you want to put even the minor obstacle of
> XML2JSON translation in the way of all these potential
> users of couchDB?
> By the way I cannot find a truly bi-directional translator;
> XML and JSON are not perfectly compatible in what
> they can handle.
> Now for a little PR. I really do appreciate all the work ya'll are
> doing. IMHO, couchDB is a great, timely concept.
> Please reconsider including XML, even if it is put on a low priority.
The CouchDB distribution might include a transparent converter
at some point. Perhaps. And probably. But it is not likely to be
supported by the core.
But this is Open Source after all and we are open for patches :-)
