update README.md

Updated readme to describe the advantages of XFlat over other embedded databases

README.md

@@ -1,7 +1,7 @@
 XFlat
 =====
 
-A lightweight embedded object-oriented schemaless non-relational DB persisting objects to flat XML files.
+A lightweight embedded no-sql object DB persisting objects to flat XML files.
 XFlat is a completely free alternative to db4o for an embedded object DB.
 
 ----
@@ -20,7 +20,7 @@ Well thats a bit harder, but you could write a class to inspect the DOM and pull
 
 Looks like you need a database.  Take a look at db4o or Sql Lite
 
-> Well I'd prefer not to have to deal with Sql, and my application is commercial.
+> Well I'd prefer not to have to deal with Sql, and I may need to inspect or transform my data as XML.
 
 Oh, well in that case XFlat is for you!
 
@@ -29,11 +29,19 @@ Oh, well in that case XFlat is for you!
 XFlat is a single lightweight JAR that persists XML DOM Elements to flat files.
 It presents as a CRUD interface to XML Elements that can be queried by ID or arbitrary XPath expressions.
 Because it is stored in flat files, XFlat is not relational and is schemaless.
-XFlat is effective for table sizes up to the dozens of KB.  Future versions will contain engines that are
+XFlat is currently effective for table sizes up to the dozens of KB.  Future versions will contain engines that are
 effective up to the hundreds of MB, using memory-mapped files.
 
 
 #### Features:
+* Pure XML data files
+  * XFlat's data files are pure XML.  This means they can be inspected, queried, transformed and manipulated by common
+XML tools like XSLT and XQuery.  It is trivial to create a process to export your entire database, or import data
+from another process into your database by directly manipulating the XML (provided the database is not running during
+the import, which is simple to control).  XFlat will automatically re-index the data files on startup if they have
+changed.
+
+
 * POJO mapping to XML
   * XFlat maps POJOs to JDOM `Element` objects using JAXB.  The underlying implementation can be swapped if necessary.
 The JAXB context is only loaded if it is used, so you can avoid it completely by specifying custom converters,
@@ -43,7 +51,8 @@ or using only the JDOM CRUD interface.
 * Queriable by XPath expressions
   * Tables can be queried by any arbitrary XPath expression using the table row as the context.  The expression
 selects a part of the `Element` that is convertible to the value which is being matched, then the matching is performed
-using Hamcrest Matchers.
+using Hamcrest Matchers.  Breaking the query into XPath expressions and values allows the engine to leverage indexes
+effectively, much more easily than if we used XQuery.  Future versions may support XQuery.
 
 
 * Multiple hot-swapped Engines (to be implemented)
@@ -52,12 +61,14 @@ the data is swapped in behind the scenes.  For example, very small tables can us
 XML DOM in-memory, while very large tables can use an engine that manipulates a memory-mapped file.
 
 
+
 * Indexing on XPath expressions (to be implemented)
   * Engines can take advantage of indexes that are based on any arbitrary XPath expression.  The expression selects a
 part of the `Element` that is converted to a `Comparable` (such as an Integer), then the engine can map that `Comparable`
 to the row and binary search indexes to improve performance.
 
 
+
 * Sharding on XPath expressions (to be implemented)
   * A table can be sharded across multiple files based on a sharding key selected by an XPath expression.  The expression
 selects a part of the `Element` that is converted to a `Comparable`, then a `RangeProvider` determines which file to store
@@ -107,4 +118,4 @@ Foo myFoo2 = fooTable.find(myFoo.getId());
 //myFoo2 is a new instance with the same data as myFoo
 ```
 
-See "Examples.md" for more examples
+See "Examples.md" for more examples