[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Getting rid of Doctype declaration header?



>Date: Mon, 2 Aug 1999 15:23:31 -0700 (MST)
>From: Dan Emory <danemory@primenet.com>
>Subject: Re: Getting rid of Doctype declaration header?
>
>Lynne:
>Here are some points you failed to mention in your description of the method
>you suggest:
>
>1. You didn't mention that the method you describe for importing SGML
>fragments only works with FM+SGML 5.5.x, not 5.1.x.
>
>2. It should have been pointed out that the SGML fragment cannot contain
>entity references unless they are all declared in the DTD.
>
>3. As you mention, on import of the SGML fragment as a text inset into the
>larger FM+SGML document, it retains the SGMLFragment element, which, in this
>case, is not a highest-level element. Now, if you export the larger
>document, including the imported text inset, is the SGMLFragment element
>also exported? If it is, then it creates invalid SGML, because SGMLFragment
>is not declared in the DTD. Consequently, the SGMLFragment element must be
>unwrapped on export by specifying in the read/write rules file the following
>rule:
>
>        fm element "SGMLFragment" unwrap;
>
>4. Even if element SGMLFragment is not exported to SGML, there still may be
>a validity problem, because the unwrapped components or the text inset may
>not be valid at that point in the document (note that the sturcture rule for
>SGMLFragment is <ANY>).
>
>5. The exported SGML document instance produced as described in 3 above will
>not contain an entity reference to the text inset/fragment. Instead, the
>entire content of the the original SGML fragment file will be contained in
>the SGML document instance. Consequently, if you open the SGML document
>instance in FM+SGML (or any other SGML-aware browser or editor), it will
>contain the content of the SGML fragment that existed at the moment it was
>originally imported as a text inset into FM+SGML. Thus, if the SGML fragment
>file was updated in the meantime, the updated version will not appear in the
>document.
>

In regards to point #3 above, when importing an SGML fragment into a
structured document, the SGMLFragment element is not created. It is only
created when the fragment is opened as a new document. So if the writer is
importing a valid fragment, then the destination document will be valid. If
any elements in the fragment are not valid, then they will be marked as
usual with red lines, or the fragment may fail to import at all. Unless the
Error Log has been suppressed, it will display the usual error messages. 

When an SGML fragment file is opened in FM+SGML, the fragment is wrapped in
the SGMLFragment element. The SGMLFragment element is not exported to SGML.
It is unwrapped when the fragment is imported into an existing structured
document or exported to SGML.

Point #4 - While the SGMLFragment may have <ANY> as its content, the
destination document doesn't and as pointed out above, the validity of the
elements in the imported fragment will be noted as the validity of any
element in the document is noted.

Point #5 - SGML fragments are exported as text entities with an appropriate
reference in the SGML document. If a declaration doesn't exist, FM+SGML
writes one. As you noted in Point# 3 this is a new feature in version 5.5.6.

I hope this clarifies these issues.

Janice McConnell
Adobe Frame Product Support

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