Support backward compatibility with content using the JBoss DNA namespaces

So far, with the ModeShape codebase, we've changed the namespace URIs for the old DNA namespaces. For example, "http://www.jboss.com/dna" was changed to "http://www.modeshape.org". This is fine for any project adopting ModeShape or any project migrating from JBoss DNA to ModeShape because they won't have any persistent data that uses the old DNA namespace URIs. However, anyone with existing persistent JBoss DNA stores will have issues with old DNA node types, paths, etc.

Note: To be clear, this issue is only about the DNA-namespaced content that was persisted by JBoss DNA and being read by ModeShape. All content using non-DNA namespaces would be unaffected and will work as expected with no modifications.

I think it may be possible to accommodate both. Those projects that have existing persistent DNA stores and that migrate to ModeShape could turn on a DNA-compatibility option that basically aliased the DNA and ModeShape URIs. Because all data is persisted using the full namespace URIs and no prefixes, the namespace registry is always consulted to obtain the prefix when converting from or to other types. By putting in aliases of the namespaces, the DNA URIs would be 'translated' into the ModeShape URI before being used to obtain the correct prefix. Of course, the NameFactory would have to be adjusted to translate the supplied namespace prior to constructing a new Name object. And the prefixes might need to be translated as well, ensuring that a path constructed with "/dna:foo/dna:bar" would really equate to the "foo" and "bar" names as if they're in the main ModeShape namespace.

This approach I believe will allow any existing persistent information in the DNA namespace(s) to be read in as belonging to the ModeShape namespace(s). If that information is not changed, the persisted form will remain using the older DNA namespaces. After all, the information hasn't been changed. However, should any of the information be changed, the new information would be in the form of the ModeShape namespaces (e.g., the Name objects would use a ModeShape namespace) and persisted as such. In other words, it doesn't matter whether the connector continues to persist the information using DNA, ModeShape, or a combination because the engine would always translate all of such content into the ModeShape namespace.

The search engine indexes would not be so lucky, because the indexes are in terms of strings that use the DNA namespaces. However, this problem could be solved by simply re-indexing the content using the ModeShape release.

I think this approach offers the least-invasive approach to solving this problem. These namespaces are built-in, and thus we would not need to offer a public API to register such aliases. Plus, if we're careful and smart, this approach might not have that much of an impact on performance. To maximize performance, the engine should default to NOT operating in "DNA-compatibility" mode. And, if there are concerns on performance, it is always possible to update the persisted data in-place.

Thoughts on this issue and approach are welcome.