OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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