[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "edunn@xxxxxxxxxxxxxxxxxxxxxxxx" <edunn@xxxxxxxxxxxxxxxxxxxxxxxx>, "Framers@xxxxxxxxxxxxxx" <Framers@xxxxxxxxxxxxxx>, "Framers@xxxxxxxxx" <Framers@xxxxxxxxx>
Subject: Re: MetaEDD Editing
From: "lprice%txstruct.com@xxxxxxxxxxxxxxxxxxxxxxxxxx" <lprice%txstruct.com@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 27 Oct 2001 14:12:14 -0400
Reply-To: lprice@xxxxxxxxxxxx
Sender: owner-framers@xxxxxxxxx
Eric, You might find it easier to do version control with your EDD if you have a textual representation of the EDD. Since the EDD is a structured document, you can treat it like any other structured document and save it to SGML. Ignore the special use of EDDs within FM+SGML and set up an SGML application for your own metatemplate. You'll need an SGML declaration that specifies a large enough value for NAMELEN and you'll probably want to set general names to be case significant (i.e., not forced to uppercase, NAMECASE GENERAL NO in the SGML declaration). --Lynne At 04:37 PM 10/26/01 -0400, edunn@transport.bombardier.com wrote: >But, my predicament is a little of my own doing. My EDD is a collection of text >insets. Each is either a Section (Format Change Lists and collections of small >simple elements) or a separate element. This was originally done so I could >track changes in elements by archiving versions and so that I could propose >changes one element at a time. I think I might just go back to an all in one and >only use my single element files for archiving purposes. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **