Re: wysiwig TeX in dia

[James Michael DuPont <mdupont777 yahoo com>]

James,
I think we are on the same wavelength.

I use Microsoft Visio 2000 and Sybase PowerDesignor at
work. PwrDsngr supports a meta-repository and has many
options to diff and merge models. Very powerfull.

Viso also supports a database repository.


> The primary advantages of storing a diagram in
> database become apparent
> when the diagram is subject to collaborative
> simultaneous use.  That's why
> CAD and Information Engineering systems offer RDBMS
> back ends.  

Yes, Even one user that has many tools hooked up to
the system. IE : Emacs, Source Code Parsers, CVS,
database structure extractors, layout tools, web
interfaces.

> 
> If several people can modify a diagram, I suppose up
> to a point they could
> use CVS or even just NFS <shudder> to keep
> themselves synchronized.  But I
> doubt the average Dia user is going to want to poke
> around in the diagram
> file looking for CVS's
> 
>    <<<<<<< diagram.dia
>        version A
>    =======
>        version B 
>    >>>>>>> 1.6
> 
> messages. :)
Powerdesignor supports diffing and patching modules in
a structured way. The XML file will be the best form
for that I think. The database can be extracted as a
log file and applied, but for merging, you need to mix
and match the changes.

> 
> The database's chief technical advantage is that
> each shape can be stored
> separately, so people can work on different parts of
> the diagram without
> getting in each other's way.  That doesn't avoid the
> need for conflict
> resolution, of course: a whole subsystem of
> comparing/choosing/merging is
> needed.  
Yes, and such tools need good GUIs, and lots of work.
But are worth it.
It you describe the changes as individual XPATHs into
the document, they will be easy to compare.

> 
> Another advantage is reuse and reporting.  If you
> want to find all the
> diagrams for clients A and C that use shapes having
> property X, it's
> surely easier to write that query in SQL than C or
> even Perl.  
Yes,and if you want to add in lots of annotations
attached to a diagram element, hrefs, documents, mails
and such. A database will be great.

> 
> Naturally, a shop full of Certified Dia
> Professionals hammering away at a
> giant collaborative diagram is light-years distant
> from the "average Linux
> end-user".  That doesn't make it a bad or pointless
> idea.  
And many people would welcome it.

> 
> Primed with suitable relaxant, it's possible to
> imagine standardized
> mapping of XML to relational databases, via a
> DTD->DDL XSLT.  
Yes, I think we have be taking the same relaxant! 

For me a UML diagram is better than the DTD,
the introspector uses a meta-model to generate the
XML, Perl and SQL from. That meta model could be
edited and extracted from DIA. making it self hosting!

>From there,
> a standard library that stores and retrieves XML
> documents using some
> database driver technology.  

That would be much better than having a built in
database. Then you can use Perl or Java to do you
database interaction via a web service or pipe.


> Then, Dia (or any other
> XML-based
> application) could have the option of using a
> filesystem or a database as
> its data store.  That is, as long as the process of
> serializing the
> diagram to XML is kept separate from the process of
> writing to the file.  
popen (X, "| perl savetodb.pl")
fprint(X, XML DATA)
pclose (X)

I think that some form of API would be usefull to do
such interfacing. 
Do we have a dia diagram of the dia object model yet?
That would be a good start, to bootstrap the
system....
Do you guys have anything against turning the DIA
sourcecode into XML via the introspector?

Then we can extract the various bits and peices and
try an generate a DIA diagram. What about C++toDia?
can that handled the Dia Source code?

Mike


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com