Better Programmatic XMI support for Modules

Hello,

I think that some module needs to provide some extra support for XMI 
files, beyond what it is doing right now. Specifically:

2. It needs to register these XMI documents with the mime type 
application/xml (non-human-readable XML files), or some other mime type 
that other modules (especially the NetBeans XML modules) can recognize 
them as XML files. Currently, XMI is not recognized.

1. It needs to register an XML catalog entry for all XML files having a 
"XMI" root element, so that modules can distinguish between XMI 
documents and "plain" XML documents.

3. There needs to be some way for modules to figure out what kind of 
model an XMI document contains. For example, I want to add a "Convert to 
SSM" action to all of the XMI documents that contain MOF 1.4 models. 
Similarly, a UML editor would only be interested in XMI documents 
containing UML models. So there needs to be some way of distinguishing 
between the metamodels for XMI documents.

4. In the filesystem explorer, XMI documents should have child nodes 
that show the XMI header, content, and differences. In particular, The 
content nodes should look just like child nodes of a repository extent, 
and it should be possible to switch between "Reflective" and "Model" 
looks of the content, just like in MDR explorer. Put another way, the 
node for the documents XMI.content element should work in the filesystem 
explorer just like any outermost package node works in the MDR explorer 
I am planning to do something similar for my SSM module, so if #1, #2, 
and #3 are solved, I could probably implement #4 after I have done it 
for my SSM module. I am thinking that there could be some kind of 
MetadataCookie that nodes can expose to indicate they have 
MOF/JMI-compliant metadata available. Then, one of the MDR modules 
should be able to use the MetadataCookie to expose the metadata in a 
standard way.

#3 seems a little difficult. How can you tell that an XMI document 
contains a UML model? I am guessing that the best way would be to look 
for XMI/XMI.header/XMI.metamodel elements. They are optional (the whole 
XMI.header is optional) but I don't know what else you would use to 
recognize the metamodel. The other problem with using XMI.metamodel is 
that there can tehnically be multiple XMI.metamodel elements (see the 
appendices of the XMI specifications for an example), but I think that 
type of thing is rare or should be rare. (In particular, I don't know 
what it means for a model to have two metamodels).

The XMI.metamodel element would give you a name and a version, so there 
would have to be some (name, version) -> metamodel mapping catalog. I 
think that such a catalog would be useful for other things outside of 
XMI processing. For example, MDRepository could have a method 
createExtent(String metamodelName, String metamodelVersion) that would 
allow you to say, e.g.:
      repository.createExtent("Model", "1.4");
      repository.createExtent("UML",   "1.3");

Possibly, each metamodel-specific module could register appropriate 
entries in this catalog in its module layer.

Note that you can't use namespaces, because (a) it might be an XMI 1.0 
document, or an XMI 1.1 document that doesn't use namespaces at all, (b) 
XMI 1.x doesn't define any way of associating namespace URI's with a 
metamodel, which means that you only have namespace prefixes to work 
with, and (c) there is not any versioning information in the namespace 
prefix (or even the namespace URI), to distinguish, say, UML 1.3 and UML 
1.4.

Please let me know what you think of these ideas. If you think these are 
ideas that should be implemented, I will file the appropriate issues 
against MDR in IssueZilla.

Thanks,
Brian