[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "Schwedland, Steve" <Schwedsl@xxxxxxxxxxxxxx>, "Schwedland, Steve" <Schwedsl@xxxxxxxxxxxxxx>, Free Framers <framers@xxxxxxxxx>
Subject: RE: Looking for a Frame+SGML 5.5 plug-in
From: Dan Emory <danemory@xxxxxxxxxxxx>
Date: Fri, 6 Nov 1998 17:58:22 -0700 (MST)
Sender: owner-framers@xxxxxxxxx
At 02:14 PM 11/6/98 -0500, Schwedland, Steve wrote: >No, the document is structured already. I do not like the random number >(actually letter) generator for Element Id's. I would like to have a >plug-in that will create a Unique ID for all of the elements so that I >can reference them later from both within Frame and in the database. OK, now I understand. If a plug-in were developed, it would have to do the following: At the moment each new element having an UniqueID attribute is added, it would have to enter a new unique ID in that element. And, if an element having that attribute is copied and pasted somewhere else (leaving the original element intact), the plug-in would have to be intelligent enough to replace the olde ID with a new one. As I recall, what FM+SGML does in this case is assign the new copied and pasted element a new object ID, and delete the old UniqueID value from the attribute, leaving the attribute value blanky until a cross-reference to it is inserted. Somehow, the plug-in would have to piggy-back on that FM+SGML action that assigns the new object ID, and follow that action up by also assigning a new UniqueID to it. That might be difficult. It might be easier to do all this in the database, rather than with an FM+SGML plug-in, allowing FM+SGML to assign its UniqueID value (call these "temporary" ID's) in the "normal" way when an element whose UniqueID attribute is empty is cross-referenced for the first time. But, each time the document is checked back into the database, a database routine would do the following: 1. It scans all of the checked-in elements for the presence of elements (i.e., those created since the document was last checked back into the database) having empty UniqueID attributes, and assigns a permanent ID to each such element. 2. It scans all of the elements for the presence of FM+SGML-assigned temporary ID's. Such temporary ID's would only exist in elements created since the last time the document was checked back into the database, and the cross-reference was also inserted before it was checked back in. In thse cases, the database routine would replaces each "temporary" ID with the new "permanent" ID. Then, for each such element whose temporary ID was replaced, the routine would scan the entire database for elements whose IDREF attribute contains the temporary ID, and replace it with the newly assigned permanent ID. All that would be required to recognize the temporary ID's would be that your numbering scheme's first character always begins with something that FM+SGML never puts in the first character. Dan Emory Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design and Database Publishing Specialists Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com 10044 Adams Ave. #208 Huntington Beach, CA 92646 ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **