Dia2, SVG, XMI, Dublin Core, aw hell just look at OO.o [RE: RE: RE:]



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]