Compound documents and XMI

Am currently thinking about compound docs and XMI. XMI 2 is very much geared for interchange between tools by mapping UML's Meta Object Facility (MOF) to W3 XML Schema (WXS). Systems engineering UML (SysML) a profile of UML for systems engineering, suggests the use of MathML for constraints. The UML Diagram Interchange Format (UML:DIF) uses Scalable Vector Graphics (SVG) as part of the presentation format.

Queue a compound document, with elements from several namespaces- interior to XMI are the xmi and uml namespaces, also some type information from wxs. Nested inside, you should have SVG and MathML.

Constraints in UML may either be opaque strings, or part of the object model.

If they are part of the object model, the body of the constraint is serialised as the expression tree in XMI.

Any language can be used an opaque expression. Unfortunantly, the type of the body of the expression is string, so you would have to escape the MathML markup as text, losing the compound document nature and complicating processing.

XMI does have an extension mechanism for vendor-specific XML data- and this may be used to package the SVG or MathML, but without the relevence of the extension data being available to the general tool. So you can have a parsed constraint that you know is the same abstract syntax tree and a MathML expression, but isn't MathML, you can have the characters that make up a MathML element as an opaque string expression, or you can embed real MathML in a extension, but it won't be recognised as being the value specification of the constraint.

I'm not sure what the vendor support for XMI2.1 is like yet, but it would be nice to get XML literals as valid content in XMI constraints and comments.