RE: Text insets in structured documents such as EDDs

["Hogan, John T. (ESA)" <john.hogan.tempe@xxxxxxxxxxxxx>]

OK, I'll bite. In the case of EDD maintenance, why do you need to enclose
your insets in a wrapper element at all? Presumably each reusable fragment
will be contained in its own uniquely named flow on a reference page or in a
separate holding document. I can't see why the individual fragments need to
be valid, as long as the EDD is valid.

You could, for example, create a 'Text Format Rules' element with all the
subrules desired and then save it in separate flow labeled 'MyFormatRule' on
the reference page. You can then, according to your own suggestion, import
the MyFormatRule flow as a text inset into every element where you wanted to
apply those rules. The EDD in the main document flow will still be valid
even though the MyFormatRule flow on the reference page is invalid.

That doesn't make the incorrect handling of SGMLFragment less of a bug, I
suppose, but why use it if it's not needed? I know I'm missing something
here.

> -----Original Message-----
> From: Lynne A. Price [mailto:lprice@txstruct.com]
> Sent: Tuesday, June 19, 2001 1:20 PM
> To: Framers@FrameUsers.com; Framers@Omsys.Com
> Subject: Text insets in structured documents such as EDDs
> 
> 
> Hi,
>   While the following comments refer to the use of text
> insets in EDDs, they conclude by describing some bugs in
> FM+SGML 6.0 that are relevant to the use of FM text insets
> in all structured documents.
>   At last year's FrameUsers conference, I described a tool
> for maintaining a set of related EDDs. A key point was
> using text insets for fragments of an EDD that occur multiple
> times. For example, numerous elements may share one or
> more attribute definitions or one or more format rules. Placing
> these definitions in text insets allows editing one
> copy to affect all instances, and ensures there are no
> inadvertent differences.
>   Like all structured flows, a structured flow used as a text
> inset must have a highest-level element. This element can
> be any element defined in the metatemplate (i.e., in the
> template used by EDDs). For such flows to be valid, though,
> the original Adobe metatemplate must be modified to make
> those elements that are used as highest-level elements of
> text insets to be valid at the highest level.
>   An alternative is to define a new element, which might be
> called TextInset, with the general rule <ANY> to be used as
> the highest level element of text insets. This approach has
> the advantage that a TextInset element can have multiple
> children and hence allows a text inset to define more than
> one attribute or more than one format rule. The approach has
> disadvantages also. The metatemplate must be modified to allow
> the TextInset element. And an FDK client is needed to unwrap
> the TextInset elements before element definitions from the
> EDD can be imported into a template.
>   By last week's thread on EDD maintenance I had been reminded
> that the TextInset element should not be needed. FM+SGML automatically
> unwraps an element named SGMLFragment when that element is the
> highest-level element of a text inset. Thus, it should be
> possible to use SGMLFragment just as I have been using TextInset
> with no need to write an FDK client to unwrap it. Furthermore,
> since the SGMLFragment element will not appear in the main
> EDD, its metatemplate does not need to account for the use of
> SGMLFragment.
>   Unfortunately, FM+SGML does not seem to handle SGMLFragment
> correctly. Both 5.5.6 and 6.0 correctly unwrap SGMLFragment
> at the highest-level of a text inset when the SGMLFragment has
> only one child; when it has multiple children, though, SGMLFragment
> is simply replaced with NoName. Furthermore, FM+SGML 6.0 has
> a tendency to crash when such text insets are updated.
>   	--Lynne
> 
> Lynne A. Price
> Text Structure Consulting, Inc.
> lprice@txstruct.com
> http://www.txstruct.com
> 
> ** To unsubscribe, send a message to majordomo@omsys.com **
> ** with "unsubscribe framers" (no quotes) in the body.   **
> 

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