Montag is a Java Web Services based system for interacting with Native XML Databases providing a Java implementation of the XML : DB API.

It's a middleware which permits heterogeneous SOAP-enabled clients, written for different platforms and languages, to operate over Native XML Databases, through the exposition of a configurable set of SOAP Web Services.

Montag version 0.7 comes with a new, clearer and simpler, configuration process.

Simply configure a main XML file, called montag-config.xml, for global web services configuration, and the local-config.xml file for working in local mode, or the remote-config.xml file for working in remote mode.

Take a look at: http://montag.sourceforge.net/docs/configuration.html

If you are interested in XML, Native XML Databases and Web Services, I invite you to participate to the Montag project subscribing its new mailing list at: http://sourceforge.net/mail/?group_id=118223

For more information, see: http://montag.sourceforge.net

Regards,

Sergio Bossa
Montag Author and Developer

Could not help but words “Native XML databases” directly correlate in my mind with recent Cameron’s joke:

Next up: XML Bitmap Image (XBI). Or maybe XML Audio Stream (XAS).

http://www.theserverside.com/news/thread.tss?thread_id=30938


Could you please explain why really somebody need a “Native XML database”, sorry but wording on main page sounds ridiculous:

If you want to use a Native XML Database, you will not be bound to a particular client, nor to a particular language for developing your client.

Are users of Oracle or even MSSQL are tied to a particular client type?

Could not help but words “Native XML databases” directly correlate in my mind with recent Cameron’s joke

Native XML Databases are not a joke but an important XML technology in great expansion, which is gaining more and more attention from users and developers.

Could you please explain why really somebody need a “Native XML database”, sorry but wording on main page sounds ridiculous

If you don't know what are you talking about, why posting useless comments?
If you are really interested, you could start taking a look at:
http://montag.sourceforge.net/links.html
and then make all the questions you want.
Else, don't make conceited posts about things you don't know.

Regards,

Sergio B.

Native XML Databases are not a joke but an important XML technology in great expansion, which is gaining more and more attention from users and developers.

Restaurants in my area (KC)are getting more and more attention, their number increases constantly, guess what? There are more and more overweight people around.

Whole XML deal looks to me as a silent plot to sell more hardware, more “lets reinvent the wheel” services which are harmful for humankind, so the criticism of the concept.
 
I could even imagine that your project does something useful (if you come up with more meaningful definition of its usefulness ) for XML addicts but Yes, I do not understand value of total XMLization, I still looking for an use case where no XML alternative available or where the alternative is less efficient. Any examples?

Whole XML deal looks to me as a silent plot to sell more hardware, more “lets reinvent the wheel” services which are harmful for humankind, so the criticism of the concept. 

I do not agree, but this is your point ...

I could even imagine that your project does something useful (if you come up with more meaningful definition of its usefulness )

If you don't know and don't understand XML DBs (NXDs), how can you talk about the meaning of something related?
A friend of mine is a brilliant Physics student, he tried hard to explain me the Maxwell equations but still I can't find where is their great importance. Maybe the equations are really meaningless, or maybe my friend is not so good? No ... the problem is my poor understanding of Physics matters.
Do you understand?

I do not understand value of total XMLization, I still looking for an use case where no XML alternative available or where the alternative is less efficient. Any examples?

I think that having several alternatives to solve a problem is always a good thing: so, having both RDBMSs and NXDs permits me to choose the best solution.
This is not the place for explaining you the advantages (and disadvantages) of a NXD, and there are many papers about this over the internet ... take a look here:
http://www.xml.com/pub/a/2001/10/31/nativexmldb.html
http://www.rpbourret.com/xml/XMLAndDatabases.htm
http://exist-db.org/

Regards,

Sergio B.

Could you please explain why really somebody need a “Native XML database”

Hmm, I guess the Xindice main page says it all:

"The benefit of a native solution is that you don't have to worry about mapping your XML to some other data structure. You just insert the data as XML and retrieve it as XML. You also gain a lot of flexibility through the semi-structured nature of XML and the schema independent model used by Xindice. This is especially valuable when you have very complex XML structures that would be difficult or impossible to map to a more structured database."

...or do you imply that semi-structured data does not exist at all and everything out there can be represented as relational? (sure it can, but at what cost?)

Very good, good point and good link.
Montag was born just to solve the problem of connecting a PHP web application to a Xindice XML DB storing a lot of XML files with hard structured data, previously mapped in a harmful, error-prone and complex relational model.
NXDs gave us a natural and simple solution.

This conversation is really not worth pursuing. I'll pick it up after you've understood the XML acronym.
For f*ck's sake, it's a MARKUP LANGUAGE, and an EXTENSIBLE one. Repeat until your ears bleed:
- XML is a spec for writing formal documents;
- XML is not a proper data storage format;
- XML is not intended for querying;
- XML is fat and slow.

To quote from one of the papers you linked to,

Thus, while it may be possible to use an XML document or documents as a database in environments with small amounts of data, few users, and modest performance requirements, this will fail in most production environments, which have many users, strict data integrity requirements, and the need for good performance.

To add SOAP on top of this NXD thing seems to me like trying really hard to make things really fat and slow.

This conversation is really not worth pursuing.

I agree.
Just some words.
You quoted this:

Thus, while it may be possible to use an XML document or documents as a database in environments with small amounts of data, few users, and modest performance requirements, this will fail in most production environments, which have many users, strict data integrity requirements, and the need for good performance.

This comes from the 2nd paragraph of this paper: http://www.rpbourret.com/xml/XMLAndDatabases.htm
and talks about XML, not NXDs, which are two different things.
You quoted the first thing you read, without paying attention to the whole document.
You're opinion are so meaningless.
And, like what you said, this conversation is really not worth pursuing.
So,
Good Bye and Good Luck,

Sergio B.

I stand corrected, I was not paying attention to the context of the quote.
The rest of the objections remain though.

Firstly food for thoughts:

http://www.xml.com/pub/a/2001/10/31/nativexmldb.html says:

[quote] The term "native XML database" (NXD) is deceiving in many ways. In fact many so-called NXDs aren't really standalone databases at all, and don't really store the XML in true native form (i.e. text). [/quote]

Secondly: semi-structured data exists but does not have to be represented as XML or relational structure, pretty often blob/clob + relational meta will suffice and excel.

Thirdly: sometimes difficulties of relational mapping are greatly exaggerated and come from lack of experience and understanding.

You also gain a lot of flexibility through the semi-structured nature of XML and the schema independent model used by Xindice.

Promises, promises.

This is especially valuable when you have very complex XML structures that would be difficult or impossible to map to a more structured database."

My first question is this: do we really need to make such mapping?
Second: if there is a real need for hierarchical data: why do not use hierarchical database like LDAP?


Well, I still want to see a real enterprise use case where XML is the best solution with expected lifespan about 5 years or longer.

My first question is this: do we really need to make such mapping? Second: if there is a real need for hierarchical data: why do not use hierarchical database like LDAP?Well, I still want to see a real enterprise use case where XML is the best solution with expected lifespan about 5 years or longer.

I think you're viewing the whole picture from a wrong point.
Native XML Databases are not a replacement for Relational, Object or Hierarchical ones.
They are simply an alternative solution, which may suit or no, regarding the needs of your application.
Some examples?

NXDs are well suited when:

- You need to store already existent XML files with complex structures, i.e. : documents with optional elements or without a schema or DTD, documents where the positional order is important, or simply documents with a complex schema or DTD.
- You need the "round-trip" property: the XML file you insert is identical to the one you get (preserving element order, CDATA sections, entities, comments and so on...).
- You want to use XML features like XPath, XUpdate or XQuery.

For example, a NXD is used in a web community gathering information about books in RDF format.

But, NXDs are not well suited when you need great responsiveness, because RDBMSs are often faster, when you need advanced transactional or security properties (in general advanced RDBMS features), or when you simply need to store data whose document format you don't care.

NXDs are a new technology and need to make many progresses, they are not designed to substitute RDBMSs and, however, they would not be able to.

I hope this will help you to watch the whole thing from the right point of view.

Regards,

Sergio B.

As I wrote about in a recent blog entry I've been looking at a usecase where NXD's could be useful. I'm using XStream to store Java object graphs as XML in an NXD (Xindice in my current tests).

Why do that? Well, here are some of the alternatives. Since my object graphs are very unstructured, changes often, and can be extended by custom plugins, using an O/R model with a RDBMS is not an option. Currently I am using a persistent Java hashtable (Jisp), but then I don't get any query capabilities, only "access by id", and schema migration is tricky.

If I use XStream to convert the graphs to XML I have mainly two options: store as CLOB in regular database, or store in an NXD. If I store the objects using CLOB's I get all the niceties of a database (ACID, transactions, etc.), but I have no query possibilities since the database doesn't understand the content.

If I use an NXD, however, the data is stored efficiently and compact, and I can use SAX to access it in order to have a performant way to access and update it (=no DOM's and no XML-as-text -> reasonably efficient), and I can use XPath to do querying. Note that with a RDBMS+CLOB-approach one typically stores the XML as plain-text, which is less efficient.

In the tests I did, for example, it was trivial to make a query that allowed me to find all references to a particular object, from anywhere in my total object graph. I have *no* (good) idea how to do that using a regular OR/RDBMS approach, since it would involve testing all tables with foreign keys, which is not very nice.

Doing schema migration on data in an NXD is trivial as well, as it simply involves performing an XSL transform directly in the database. I have recently made a schema migration of our Jisp-database using this technique, but I had to explicitly export/transform/import the data for it to work. A big hassle.

All in all, using a NXD with a XML-serialization package (such as XStream) was a very easy to use and powerful combination, especially compared with the alternatives.

FWIW, and YMMV.

Truly amazing, "native" XML "databases", accessed over *SOAP* ! That will put a nail in Oracle's coffin.

Scary, truly, deeply frightening.

Sergio, take a look at this for a mild reality check. Also this.
Yes, the free lunch is over and you're making fresh cookies from rotten left-overs.

You take care now.

Sergio, take a look at this for a mild reality check.

I read, it's nothing new.
You make me laugh if you think it's a good argument against NXDs and other XML technologies.

Truly amazing, "native" XML "databases", accessed over *SOAP* ! That will put a nail in Oracle's coffin.Scary, truly, deeply frightening.

I don't want to start a flame about NXDs and XML and I don't have time to waste.
You are free to think that NXDs, XML, Web Services, SOAP or everything you want, are useless.
You can think they are evil.
You can say this to all the folks that believe in those technologies, investing time and money.
I only hope you really know what you say.

Regards,

Sergio B.

Sergio, take a look at this for a mild reality check. Also this

The XML section in the Joel On Software article is a bit lame by the way. Indexes and query optimizers exist for databases working with semistructured data as well (f.e. the Lore system which existed even before XML)

The XML section in the Joel On Software article is a bit lame by the way.

Sort of, yes.
The irony of the situation is that in order for Joel to be wrong some pretty wicked stuff has to happen, such as storing XML documents in a non-text manner, maintain all sorts of indexes and implement query optimisers and such, most if not all of these coming from relational database technology.

I for one think that "very unstructured", "semistructured" data is a bad thing. Back in the days when I started working with XML I always felt like a fraud for not starting out with some formal definition of the document structure - the DTD.

Sergio, please take no offence, but I find the whole idea of storing data in XML and then accessing it through an XML-based protocol, well, either laughable or naive. I mean for heaven's sake Sun wants to do binary web services, RMI's wire protocol is replaced by IIOP, some databases compress data before it hits the storage - using researched and purposely built algorithms, and you want to encapsulate xml in xml. Might as well use paper and pencil for storage, ask the queries overs the phone and fax the answers.

Of course this is an exaggeration but I fail to see why I should use _document_ technologies to store/query/retrieve data.

I for one think that "very unstructured", "semistructured" data is a bad thing.

Data, of any kind, cannot be either inherently "good" or "bad". It can be appropriately applied or not, though, but that's an entirely different issue.

Back in the days when I started working with XML I always felt like a fraud for not starting out with some formal definition of the document structure - the DTD.

That is a personal belief (which is fine, but realize that it is only that) and has nothing to do with this particular discussion.

Sergio, please take no offence, but I find the whole idea of storing data in XML and then accessing it through an XML-based protocol, well, either laughable or naive. I mean for heaven's sake Sun wants to do binary web services, RMI's wire protocol is replaced by IIOP, some databases compress data before it hits the storage - using researched and purposely built algorithms, and you want to encapsulate xml in xml. Might as well use paper and pencil for storage, ask the queries overs the phone and fax the answers.Of course this is an exaggeration but I fail to see why I should use _document_ technologies to store/query/retrieve data.

Then don't.

For myself, I see no problem with using document technologies to store/query/retrieve documents, but maybe that's just me.

Me:

use _document_ technologies to store/query/retrieve _data_

Rickard:

using document technologies to store/query/retrieve documents

You're obviously right Rickard; please note the difference between our statements - emphasis on 'data' added on this edit.

Me:

use _document_ technologies to store/query/retrieve _data_

Rickard:

using document technologies to store/query/retrieve documents

You're obviously right Rickard; please note the difference between our statements - emphasis on 'data' added on this edit.

Yes, good, but you are talking about "using _document_ technologies to store/query/retrieve _data_".
We all are discussing about XML, NXDs and "using _document_ technologies to store/query/retrieve _documents_".
I hope the whole discussion was a misunderstanding.

Regards,

Sergio B.

Me:

use _document_ technologies to store/query/retrieve _data_

Rickard:

using document technologies to store/query/retrieve documents

You're obviously right Rickard; please note the difference between our statements - emphasis on 'data' added on this edit.

Yes, and the difference in my previous entry was intentional.

And as you say, it is obviously right.

Me:

use _document_ technologies to store/query/retrieve _data_

Rickard:

using document technologies to store/query/retrieve documents

You're obviously right Rickard; please note the difference between our statements - emphasis on 'data' added on this edit.

Yes, and the difference in my previous entry was intentional. And as you say, it is obviously right.

I think I might see where your confusion comes from. You see, "documents" are "structured data". So, they are "data" too! But with structure!

Sergio, please take no offence, but I find the whole idea of storing data in XML and then accessing it through an XML-based protocol, well, either laughable or naive. I mean for heaven's sake Sun wants to do binary web services, RMI's wire protocol is replaced by IIOP, some databases compress data before it hits the storage - using researched and purposely built algorithms, and you want to encapsulate xml in xml. Might as well use paper and pencil for storage, ask the queries overs the phone and fax the answers.Of course this is an exaggeration but I fail to see why I should use _document_ technologies to store/query/retrieve data.

I take no offence, Adrian, there's no problem.
But, like pointed before, we are not talking about storing data in XML and then accessing it through an XML-based protocol, or so.
We are talking about document technologies and the need for storing documents.

Regards,

Sergio B.

Sergio, please pay attention:

Montag is a Java Web Services based system for interacting with Native XML Databases providing a Java implementation of the XML : DB API.

versus:

We are talking about document technologies and the need for storing documents.

Do I really need to count occurrences of "data" versus "document" in the whole thread ?..

I write my documentation in DocBook/XML; I store my data in properly (hopefully!) designed relational databases.

I've spent days reading up on all sorts of projects related to XML and databases, ranging from childish attempts/projects and blog entries to commercial products and academic research, so I have a little bit of an idea what I'm talking about.

Terms like NXD are gibberish, at best the result of a confusion made by overly-excited people with an urge to invent and revolutionise.
This has the unfortunate down-side of people not paying attention to the actual technology hiding behind badly drawn posters sporting hyped, buzzword-compliant text.

Caveat auctor.

Terms like NXD are gibberish, at best the result of a confusion made by overly-excited people with an urge to invent and revolutionise.This has the unfortunate down-side of people not paying attention to the actual technology hiding behind badly drawn posters sporting hyped, buzzword-compliant text.Caveat auctor.

Ok.
But you also wrote:

Me:

use _document_ technologies to store/query/retrieve _data_

Rickard:

using document technologies to store/query/retrieve documents

You're obviously right Rickard; please note the difference between our statements - emphasis on 'data' added on this edit.

So, can you explain me in what way is Rickard right?
Now I'm confused.
If you think NXDs are gibberish, and Rickard uses them, why did you say he's right?
Can you give a better solution to Rickard's problem?