I've created issue http://argouml.tigris.org/issues/show_bug.cgi?id=4431
Cheers Bob. On 8/31/06, Bob Tarling <[EMAIL PROTECTED]> wrote:
I'd be suprised if any third party tools were reading the argo,pgml,todo but I guess it's possible. I can reintoduce these back into a zargo project but if so I'd prefer this only stayed in place for one major release. Of course we should still be able to load old style. I think a .zargo file should continue to be our standard extension, it's recognisable to the user and is still just a zip file containing XML docs (although singular for future). Bob. On 8/30/06, Robert Buckley <[EMAIL PROTECTED]> wrote: > I think I agree with Tom, change for the sake of change is bad. > > I also agree with Bob that change for the sake of keeping up with standards > is good. > > Keeping up with standards, however, should not preclude maintaining > backwards compatibility as a courtesy to people, if any, who are dependent > upon it. Keeping the option of storing a traditional .zargo file with its > pgml's etc. would be such a courtesy. > > I don't have an opinion on how many subsequent releases should keep such an > ability. > > As I understand it, there are currently two ways to store a project. One is > as an .xmi file with everything in it. The other is a .zargo file which is > now nothing more than a zipped .xmi file. > > It would seem to me that a .zargo file should be what it always was and if > the user wants the .xmi file to be zipped he is free to do so externally. > > If you want a third option to store a zipped xmi file (probably called > .zxmi) as a convience that is fine. > > ----- Original Message ----- > From: "Bob Tarling" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, August 28, 2006 6:14 AM > Subject: Re: FW: [argouml-dev] Re: Save entire project in XMI > > > > On 8/22/06, Tom Morris <[EMAIL PROTECTED]> wrote: > >> Are Bob and I the only ones with an opinion on this? The implementation > >> has > >> gone ahead with effectively no discussion. > > > > Well I did announce my intention a couple of times. It's unfortunate I > > missed your email. > > > >> I've seen no stated benefit for this change to a *major* external > >> interface. > >> Are we really sure we understand the knock on effects of entirely > >> dropping > >> one file format and making major changes to the others? Change for the > >> sake > >> of change is bad, particularly in such a critical area that we've been > >> working so hard to stabilize. > > > > The change was not just for its own sake. The reason for change was to > > use an industry standard extension for persistence. We need to keep as > > close to standards as we can. > > > >> 3. I thought the UML 2.x structure was to have the diagrams in their own > >> XMI > >> file(s) separate from the model. If I'm remembering this correctly, > >> merging > >> everything into a single file represents a detour from the long term > >> direction that we'll have to undo later. > > > > I thought in UML2 diagrams were contained in the same XMI as the model. > > > >> I suspect > >> the current implementation isn't multi-byte character set safe. > > > > I think the general use of InputStream should be replaced with Reader. > > This would allow me to use CharArrayReader or StringReader as opposed > > to ByteArrayInputStream. > > > > Bob. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
