M.Rys

@srikalyan: There is not really an ontology behind it (yet). We are extracting keyphrases or tags (in this case only 1-grams, although the algorithms could also handle n-grams). That information is made accessible in relational form through the table-valued functions. Generating and supporting ontologies is definitively something we are looking into for the future. How close that future is depends on many things though. What do you mean with access priviledges and authentication? This feature is integrated into SQL Server with Fulltext search so you have the standard SQL Server access controls.

One update, the languages supported now include several different versions of Chinese

@BLinden:All the SQL Server Full-text iFilters are supported. So in the case of XML or HTML, we will not index the markup tags or attribute names. If you want PDF support, you will need to install a third-party PDF iFilter such as Adobe's or FoxIt's.

"Is at least the fact that all of this is done with strong typing something new?"

This depends. XQuery and SQL both provide for both static and strong typing on declarative expressions. However, the integration into the programming language type system is well-done (and thus could be considered "novel").

Thanks for the comments.

Regarding the killer use cases for XML: I try to address this somewhat in the non-demo part. If your XML describes basically relational data that you want to repurpose, slice and dice in different ways, shredding it into relational form and doing normalization is a good idea. If the XML OTOH is representing a markup document (such as a WordML or XHTML document), or the XML represents a logical unit (aka object) which you want to store and retrieve as efficiently as possible while still having the ability to query into its components, storing the data as XML is easier and often preferrable.

Best regards
Michael