Re: SGML fragments imported by reference problems - more details

[Adrie Berg <adrie.berg@xxxxxxxxxxx>]

Hi,

Hope this clears up things a bit.
>It's not at all clear from your description what the problem is.
>1. Are the "fragments" :
>    b. Each fragment in a separate file, that is separate from the file 
> containing the Target Document?

The fragments are all separate files, containing an SGML fragment. These 
fragments are all valid, and once imported the resulting document is also 
always valid. Although these FrameMaker documents contain SGML fragments, 
they are saved in the FM format. I hope the example below explains things 
more clearly.

>9. Your description that the "first paragraph layout of the fragment is 
>repeated at the end" doesn't seem to gibe with what you describe later, 
>namely that:
>
>"In the above example you can see the 3. being incorrect. It somehow a 
>part of the imported fragment"
>Is the problem that the second line of yyyy under 2 above is a "repeat of 
>the first line", or is the problem that 3 (which presumably is in the 
>Target Document) is becoming part of the fragment under 2? I conclude that 
>it's the latter.

Below is a more accurate example.
In the example the numbering is added by the EDD to certain elements in the 
SGML structure. The numbers 1,2 and 4 are added because the line contains a 
section element. The numbers 1, 2 and 4 are part of the main document. The 
number 3 is inserted into the main document after the fragment with the P 
is imported. With element tags turned on the graphic representation of the 
document shows that the line with the 3 in it is part of the imported 
fragment. But when looking at the fragment there is nothing in there which 
should cause the 3 to appear.

The weird thing is that the end tag is displayed on the empty line. The EDD 
adds numbering to the section element, and the end section tag is displayed 
on the last line, so I thought this could be causing the problem, but im 
not sure how to repair it.

An other example: (Structure of the fragment, a separate .fm file)
<SGMLfragment><P>yyy</P></SGMLfragment>

Structure of the main document, a separate .fm file:

<Section><Title>xxx</Title>
<P>xxx</P></Section>
<Section><Title>xxx</Title>
<P>yyy</P>                              (<--- imported by reference 
fragment with a single valid p element)
</Section>                                 (<--- somehow appears on a new 
line!)
<Section><Title>xxx</Title>
<P>xxx</P></Section>

With layout this results into:

1. <Section><Title>xxx</Title>
<P>xxx</P></Section>
2. <Section><Title>xxx</Title>  (<--- the fragment appears to start 
directly after </title>)
<P>yyy</P>                            (<--- imported by reference fragment 
with a p element)
3. </Section>                           (<--- the fragment appears to stop 
right before </Section>)
4. <Section><Title>xxx</Title>
<P>xxx</P></Section>

Somehow a newline was sneaked into the fragment, this newline is not in the 
original fragment, and its not removable from the main document without 
deleting the fragment.

>2. Are the numbers 1, 2, 3, and 4 in your example part of the Target 
>Document or the fragments? If the answer is that they're part of the 
>Target Document, are you inserting the fragments inside the same elements 
>that contain those numbers in the Target Document?

The numbers 1,2,3 and 4 in the example are numbering things linked to SGML 
elements by the EDD. The EDD adds numbering to some paragraphs.

>3. Does the element structure of the fragments conform to the same DTD/EDD 
>as that used to create the Target Document? If not, that's likely to be 
>the cause.

Yes, both the SGML fragments as the main document are valid.

>4. Are the fragments valid at the text insertion points where they are 
>being imported? You should be able to check this by re-validating the 
>Target Document after you've imported the fragments. If the validator 
>reports an error at the location of the fragments, that's the cause of the 
>problem.

The document is valid.

>5. Are you sure that there are no ad hoc format overrides to the 
>EDD-specified format rules for the fragments or the Target Document? After 
>importing the fragments into the Target Document, you can check this by 
>re-importing the Target Document's element definitions back into itself 
>with "Remove Format Rule Overrides" turned on.  If this corrects the 
>problem, then you've found the cause.

The EDD adds formating information to the document and to the SGML 
fragments. I tries your suggestion about removing overrides, but the effect 
was unchanged.

>6. Are you importing the fragments into the Target Document by copy or by 
>reference? Change to the other option, and re-import. If the problem is 
>eliminated, you've found the cause.

The fragments are imported by reference. Its not possible to inport as a 
copy, because the referenced document are registered in an CMS-like system, 
which analysed the main documents for imported parts.

>7. When you import the fragments, are you specifying that they be 
>reformatted according to the target document, or are you specifying that 
>the formatting in the fragment be preserved? If you've selected preserving 
>the formatting in the fragment files, try changing the option to reformat 
>according to the target document. If the problem is eliminated, you've 
>found the cause.

Ive tried both, with no effect. By default the layout of the fragments is 
disregarded, and the layout of the main document is used.


Thanks for your help,
Adrie Berg


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