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]
