Re: [FrameSGML] Text Inset Bug in FM+SGML 6.0 and 5.5

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 09:13 AM 8/1/01 -0400, edunn@transport.bombardier.com wrote:


>Well said Dan and I agree completely with you. Wrapper elements properly 
>planned
>and executed can be a great tool to chunk the information and use insets.
>
>But I would first strive to make the DTD structured in such a way that the
>wrapper elements are not required. Or, at least are not special cases.
=========================================
In addition to the advantages of this approach in creating text insets and 
in managing/retrieving information chunks, it can be a boon to 
collaborative authoring and information management.

The lead writer creates a "master" document in FM+SGML, which is, in 
essence, a "skeleton." The lead writer also creates, for each writer, an 
FM+SGML fragment file in which a separate, descriptively-named text flow is 
created for each discrete "chunk" of information that is assigned to that 
writer. In each text flow, the lead writer also inserts the (valid at the 
highest level) FragWrapper element, and enters the applicable values for 
the attributes that constitute the enriched metadata required to manage and 
describe each fragment. Once that is all done, the lead writer goes back to 
the master document, and imports by reference (as a text inset) each 
fragment at its location within the skeleton. At that point, the master 
document is essentially an outline, and each text inset is is an empty 
FragWrapper, but the metadata in the FragWrapper's attributes provide a 
detailed description of each information chunk. As the writing effort 
proceeds, the lead writer can open the master document and see the current 
status of each writer's contributions.

This approach to collaborative authoring would be particularly valuable in 
a large proposal effort, where many of of the contributors are not 
professional writers, and each contributor may be required to quickly 
produce a number of  (relatively small) pieces which appear at different 
locations within the proposal outline.

In any writing environment, the approach described here can greatly 
facilitate information reuse, because each chunk can be stored in, and 
quickly retrieved from, an SGML/XML database repository for viewing in 
FM+SGML. An appropriate database query directed at the enriched metadata in 
FragWrapper elements would yield all the candidates for reuse for a 
particular requirement, and the best candidate(s) could be chosen and 
modified/adapted as needed.

Also, if the appropriate metadata were included in FragWrapper elements, 
revision and effectivity tracking could easily be accomplished at a 
granularity well below the document file level.

Finally, if all FragWrapper elements were individually stored in an 
SGML/XML repository, it would probably be feasible to convert, on demand, 
the FragWrapper metadata into XML-style RDFs for each FragWrapper element.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
177 Riverside Ave., STE F, #1151, Newport Beach, CA 92663
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **