Re: Better Programmatic XMI support for Modules

Hi Brian,
yes, these are good ideas - please file new requests for features. In 
fact we were thinking about doing this a long time ago, however 
currently our highest priority is to make sure that the integration with 
Java will work and it will be reasonably fast. This kind of features is 
"nice to have" for us and very likely we will not have resources to 
implement it before the Java-MDR integration is completed.
Martin

Brian Smith wrote:
> 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
>