Far more detail than you provide is needed to adequately answer this question.
The technologies that you use will be driven by your specific requirements, both functional and non-functional. So in order to know what will best fit your needs, you need to perform requirements engineering. Figure out exactly what the end user wants, and then you'll have a better idea of what tools you can use to get from where you are now to where you need to be. But it's important to focus on both the quality attributes and non-functional requirements as it is the functional requirements.
If you've never done requirements engineering before, I would highly recommend reading the works of Karl Wiegers. He has published two key books - Software Requirements and More About Software Requirements. The first book was required reading in the course I took on software requirements engineering. Wiegers also has a website called Process Impact, which might have some helpful resources and information.
Once you have your requirements, it will be much easier to determine which technology stack can best solve your problems.
However, I do have a few suggestions for you, in the interim:
You have experience with Java, so sticking with the Java environment is probably a safe bet. Don't use a technology to solve every problem that you come across just because you are familiar and feel safe, however. Make sure it can actually solve the problems that you are trying to solve. Otherwise, you are just creating more work for yourself and whoever else has to maintain your software.
Regardless of which solution you choose, the company is going to expect documentation. Depending on the terms of work, you will at least be expected to provide instructions on how to deploy the software and then instructions on how the end user can actually use the system you built. However, there's lots of other things that need to be documented, such as the agreed upon requirements, the design or the final state of implementation when you turn it over, defect reports, time reports, and so on. Make sure you know what you have to deliver, besides working software.
In terms of the database, you have choices between database servers (such as MySQL and PostgresSQL) and embedded databases (such as SQLite and HSQLDB). There are also the NoSQL (such as Hadoop) solutions for data stores. You might want to look into the capabilities of each one and see how you can best meet your requirements. You might need to deploy both, even, depending on the specific requirements. However, you can't choose until you have requirements.
Regardless of the database you use, you'll probably have to be comfortable with things like JDBC and various ORM layers. If you decide to go the web app route, you'll have to be familiar and make choices between Struts, Spring, and a number of other web application frameworks. Be ready to evaluate a number of competing tools, libraries, and frameworks against your requirements. And don't be afraid to throw things away. I believe it was a tip in The Pragmatic Programmer - plan to throw one away. You are going to be making mistakes, and you need to learn from those mistakes throughout this project. It'll help you in the long run.
So, in short, figure out exactly what you have to build before you even try to start thinking about technologies. Given your post, you aren't providing enough information for any reasonable engineer to give any suggestions. And if you don't know or can't specify what you are building to another engineer, there's no way you can build it.
I think you are really asking a broader question, "is having a strict definition of a file format a good thing for a rapidly evolving project".
To answer your immediate question, though: yes, they are. The XML schema gives you a strict definition of the format, answer a lot of questions about validity, provides great documentation, and allows you to confidently know that a specific version of the document has a specific form.
They are not the be-all and end-all, though: they define structure, not semantics, so you can still change the "meaning" of a tag between version of the document without having to change the schema. That causes just as much trouble.
To answer the question I think you are asking: yes, the XML schema is a good thing.
It is forcing you to address a painful fact, which is that your data exchange is constantly changing versions, and that means you have to adapt your system to account for that.
If you only had the IOS model, where you take a "rough guess" at what this version means, you open the door to all sorts of trouble in the long run. For example, it becomes trivial for someone to assume that "element foo being present means version 1.2, so tag bar means ...".
That is great, right until version 2.0 adds back the foo element, with a different meaning, and tag bar isn't even there. Welcome to "inconsistent behaviour" city.
If you use XML without schemas, or JSON, or something else that doesn't impose that cost on you then only a tiny bit of the problem goes away. You still have to deal with all four versions of the input, but you have less tools to help you out.
You should, in my opinion, generally prefer to make the pain of changes proportional to their real, long term cost. Changing the data exchange format has a high long term cost - you have to deal with compatibility, with data upgrades, and that sort of thing.
If that costs little you will be tempted to do it a lot, and then will pay the maintenance cost tomorrow. If it costs more now, you might think harder - can you do more than one thing in this change? Can you get away without it? Can you do it smarter?
In short, I think your real problem is that your file format changes often, not that you used (or didn't use) XML schemas.
(Also, are your users really happy if the server or client randomly drops content that is represented in the newer version? I would be surprised if that remains true forever - another of those long term costs you need to recognise somewhere...)
Best Answer
Storing the configuration of the program externally allows you to avoid needing to recompile the program when something changes. Switch from
databaseA
todatabaseB
? Modify the property file rather than modify the hard coded values and recompile from source.What's more, Java offers a class as part of its standard runtime environment that facilitates this - the
Properties
class. This class can either take a.properties
file or an.xml
file that matches the dtd specified at http://java.sun.com/dtd/properties.dtd (it really is a rather simple one - its the same as the one in the javadoc).With the Properties class, you load it in, and then you can easily call
getProperty(String key)
orgetProperty(String key, String defaultValue)
and get your values out of it. This is much easier than loading values from a custom xml file and all the xml or xpath processing that you would have to do with it. Furthermore, its a known thing and easier to get right.That's the property file.
And then you've got the corresponding bit of Java...
for reading it out. This makes the code a bit more self documenting, a safeguard against not having the file with a default value.
If you really wanted to use xml instead of a properties file, it would look like:
But again, the key point is to move the values out of the code and into external files that are easier to work with. And Java already has the tools for reading those back into the system.