XMI2HTML (Re: PROPOSAL (round 2): Extensions to MDR XMI API)

Holger Krug wrote:
> On Thu, Aug 01, 2002 at 06:13:53PM +0200, Martin Matula wrote:
> 
> Returning to XMI/MDR:
> 
> Using a XMI2HTML conversion XSLT stylesheet it would be very easy to
> provide online repository browsing in the following way:
> 
>     (1)   (2)     (3)
> MDR -> XMI -> HTML -> HTML
> 
> (1) XMIWriter writes to ChangeSource
> (2) XSLT_based conversion to HTML
> (3) putting on a web-page with Menu etc. (also XSLT-based)

Yes, this would be a good demonstration. Actually, I have a 
half-complete XMI JavaDoc thing that I did last year when learning XSLT. 
I use it daily even in its incomplete state. Perhaps it would be useful 
to everybody?

I feel that the flexibility offered by the XMI serialization rules makes 
using XSLT with XMI way too complicated, especially if you are trying to 
write XSLT stylesheets that would work with implementations from variety 
of vendors (i.e. make stylesheets that work with any document that 
follows the XMI standard). I found that I had to use a lot of extension 
functions to prevent myself from going mad. That is why I was thinking 
to finish that project sometime using servlets that read directly from 
the repository, perhaps generating either HTML directly or a "canonical 
XMI" that is easier to transform with XMI. Perhaps, I could put the 
effort into creating a "Canonical XMI" implementation of XMIWriter. But 
that would require a definition of Canonical XMI. I'm thinking:
    (a) All single-valued xmi.idref links get converted to HREF's.
    (b) All multiple-valued xmi.idrefs get converted to HREF's on
        multiple elements.
    (c) All attribute and reference values are given as elements
       (not attributes).
    (d) All values for a multi-valued feature are enclosed in a single
        <Metamodel:Clasname.featurename> element.
    (e) The default value mechanism is not used.

(a), (b), and (e) would result in documents that don't require a DTD for 
useful XSLT processing. (a), (b), (c), and (e) would result in documents 
that are much less human-readable, and much(?) larger, but much easier 
to process with XSLT. And (d) would result in more human-readable, 
smaller, and easier-to-transform documents.

- Brian