[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: XMI Difficulties
The following is an abridged version of a message I sent to the XMI spec leaders (Sridhar Iyengar and Steven Brodsky) about XMI 1.1 - I mentioned it on the Friday call. For this posting I've omitted a section explaining the Docbook extension mechanism. Difficulties in using XMI 1.1 for OASIS and EBXML Registry Documents Disclaimer: This document is concerned with the generation of DTDs to define document types for which document instances may be composed independently of any UML or MOF implementation. That is not the goal of XMI 1.1, which is intended as a transfer syntax. So the problems noted here arise from the use (or prospective use) of XMI outside its intended domain of applicability. And I really do appreciate the work that's gone into XMI! Problem Statement OASIS's Registry and Repository TC has developed a specification for implementing an ISO/IEC 11179 registry for a repository of SGML- and XML-related entities. This specification includes DTDs for specific documents required in the registration process. These DTDs have been composed by hand, and reflect the present 11179, without the proposed X3.285 revision, which is specified using UML models. EBXML's Registry and Repository WG is developing a UML model of use cases for a registry and repository for commerce-related UML models and related entities (including XML-related entities). It is desired to extend the OASIS specification to meet EBXML's needs. Hence it would be desireable to replace the hand-composed OASIS DTDs with DTDs generated from EBXML's UML model of use cases. (Just how to generate the specific documents required is an issue I won't consider here.) To add to this mix, it appears that X3.285 may be reaching the point at which it could be put into practice; if that were possible, it might be that much of the work of the OASIS and EBXML groups has been done already, and we could just generate the DTDs we need, using XMI's DTD Production Rules. Unfortunately, DTDs generated using XMI's DTD Production Rules are not sufficiently constrained to allow validation of documents composed outside of an environment that enforces the UML model they (partially) express - and for OASIS, at least, we cannot assume such an environment. Put another way, any number of documents can be composed that will validate against a DTD generated using XMI's DTD Production Rules, but that do not contain the information required by the model (contra XMI 1.1, 6.2, second para). Specifics 1. The XMI DTD (I used ad/99-10-05, XMI 1.1 RTF UML DTD) is too loose to begin with. Even the degenerate case <XMI> </XMI> is valid, as none of the XMI element's contents is required. (Even the CWM DTD, which requires XMI.header, does not require anything else, including all the real content, although it is an invalid DTD due to ambiguity.) In addition, the liberal use of the ANY keyword, while well intentioned, permits nonsensical combinations of declared elements. (See below for remarks on a better extension mechanism for DTD syntax.) 2. The generated DTDs are much looser than the models because of the design decision to eschew the + and ? repetition operators (e.g. those in Appendix C of the MOF 1.3 document). 3. For OASIS and probably for EBXML purposes, it is not useful for the doctype of instances always to be XMI. What is wanted is a DTD at the level of content shown in the Letter DTD of MOF 1.3 C-153, for use independent of the XMI.content element. (Invariably, programmers want to identify the document type from the root element; the references to the model, metamodel, and anything else could be conveyed by FIXED attributes within the generated content DTD if needed.) 4. The extension mechanism, using the XMI.extension element, is much better thought out than such mechanisms generally are, but presents certain difficulties in itself: - It probably shouldn't be present in generated DTDs at all. - When added to a PCDATA content model it produces mixed content, which SGMLlers can live with but programmers new to XML find all but impossible. - As the content model of XMI.extension is ANY, an extension declared for use in a specific context can appear anywhere, within an XMI.extension element. - Most XMLlers would rather not have to deal with the XMI.extension container element around the actual extension. - BTW, what is the difference between XMI.extension and XMI.extensions? The XMI 1.1 spec isn't terribly clear. So, What To Do? We could generate the desired DTDs, extract the parts that aren't boilerplate XMI, and rework the content models (perhaps by algorithm and Perl) to tighten them up to the point they reflect the model. We could define a different set of DTD Production Rules and build software to implement them. We could go back to XMI 1.0 and see if that works better. We could require that OASIS and EBXML registry documents be produced by software that enforces the rules of the model rather than of the generated DTD, and that they be consumed by software that acts similarly. We can state the problem and invite other solutions (which is what I'm doing).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC