Dia2, SVG, XMI, Dublin Core, aw hell just look at OO.o [RE: RE: RE:]
From: Aaron Trevena <tj droogs org>
To: dia-list gnome org
Subject: Dia2, SVG, XMI, Dublin Core, aw hell just look at OO.o [RE: RE: RE:]
Date: Sat, 29 Mar 2003 18:09:44 +0000 (GMT)
> From: Alan Horkan <horkana@maths.tcd.ie>
> sorry i am mostly going to skip responding directly to the thread.
ditto - already posted on the thread.
> You want XML (eXtensible Markup Language) and you want to do UML type
> stuff in it then you want XMI (XML MetaData Interchange). IBM Eclipse is
> doing something called EMF (not to be confused with Microsofts Enhanced
> Metafile .emf, close relation of Windows MetaFile .wmf).
ROFLO - XMI ??
Sounds great in theory, in practice its next to useless - I don't need to
know if the XML is an entity of
we.use.very.long.names.for.everthing.object.subtype.int.vector.suck.eggs
> One of my problems with the dia file is that in effect it is just a list
> of objects. It might be possible to reinterpret this as SMIL.
This makes it very easy to parse, using perls lovelly XML::Simple. It is a
good thing. Having succesfully written code to read and write dia files I
am rather happy with it. Unlike argouml's XMI/XML cruft and the
over-complex fugly stuff that other vendors produce.
As I type I am downloading kivio - hopefully its output will be parsable
and I won't have to install a new version of java, glibc, gmake and just
to get it running.
> While messing about with Dia and having renamed some of my shapes i found
> that old save files would spew a s---load of not found errors and not
> display anything useful. Imagine what would happen if we had thousands of
> shapes but did not ship with all of them. Document exchange and
> portability is a nightmare. It would be nice if the save format was more
> robust and the SVG was inlined into the actual Dia file so that if
> hte object as unavailable at least there would be a placeholder
> image to display instead.
This sounds like a good idea.
> I really dont like the programmed objects, it would not be so bad if they
> were SVG for the visual parts. Binary file formats, ick. Mixed and
> matched XML with Binary is even worse.
I take it this is a custom object tghing - I've never had to deal with any
binary stuff in Dia xml output.
> If you are not particularly interested in UML and more in the diagramming
> aspect then in the short term you can keep things simpler and focus on
> getting Dia to round trip SVG.
SVG is just a graphical format and is thereforesuited for the final
output, as opposed to internal storage, exporting to SVG is great but I
have never needed to output SVG because a) nobody has anything to render
it in and b) iof you are processing the diagram, you don't need to be told
how to draw it, just what it is.
> I would be inclined to plan a Dia2 file format seperately without breaking
> what we currently have. This notional Dia2 format would combine all the
> aforementioned standards with the working bits we already have.
The important thing is to keep presentation and application information
seperate. Its not hard to convert the current XML to SVG if you need to,
in fact its trivial and you can manipulate it as you see fit.
--
Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
AutoDia --- Automatic UML and HTML Specifications from Perl, C++
and Any Datasource with a Handler. http://droogs.org/autodia