Re: Getting rid of Doctype declaration header?

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 04:33 PM 8/2/99 -0700, Lynne A. Price wrote:
>Dan,
>  FM+SGML's fragment support could be extended. Nevertheless, there
>are many situation it does handle quite nicely.
>  One shortcoming you did not mention is that there is no provision
>for inherited exceptions on import.
=====================================================
How about an example of what you mean by "inherited exceptions"?
===============================================================
>When FM+SGML exports a complete SGML document, it will generate
>declarations for any SGML text insets that do not have declarations.
=====================================================================
Let's see. Suppose the original document is being authored in FM+SGML, and
during that authoring process I import by reference SGML fragments as text
insets into the larger FM+SGML document that I'm authoring. This is what you
described in your original post to Nasser Silakhori, as follows:

"You can then import this fragment into your larger document as
needed. When you create the text inset, the Unknown File Type
dialog appears. Select SGML as the file type."

Now, the only way such an imported by reference text inset can be replaced
by an entity reference on export to SGML is by use of an "is fm text inset"
read/write rule of the following form:
        entity "SOI"{
        is fm text inset "filename"
        in body (or reference) flow "flowname";
        }
Where:
"filename" is the name of the file with the flowname containing the text
inset,         and
"SOI" is the same name that appears as the bracketed SOI of the
corresponding SGML entity declaration. That entity declaration, which must
be in the DTD, has the form:
        <!ENTITY entname SDATA "[SOI]" >
Where the bracketed SOI is a name (not a filename) whose "lookup location"
is in the read/write rules on the FM+SGML side, and is in an entity catalog
on the SGML side.

But under the heading "Details" for the "is fm text inset" read/write rule
in the V5.5 Developers Guide, the second bullet states: 

        "You cannot us an SGML file as the source of the text inset."

It is, therefore, impossible for FM+SGML to replace such an imported SGML
fragment with an entity reference and an entity declaration on export to
SGML. Instead, if you want the text inset to be replaced by an entity
reference on export, you must import into the larger FM+SGML document not
the SGML fragment, but instead the version of the fragment that is contained
in a text flow of an FM+SGML text inset file. Then, with the read/write rule
and entity declaration described above, FM+SGML will, on export to SGML,
replace the text inset with an entity reference in the exported SGML
document instance. Now, as stated above, on the SGML side an entity catalog
specifies the SOI of the SGML fragment as follows:
        ENTITY entname "filename"
where filename is the filename of the SGML fragment file that was originally
exported from the FM+SGML text inset file that contains the FM+SGML version
of the fragment.

But this means that there are two versions of the entity--one in an SGML
fragment file, and the other in an FM+SGML text inset file. Thus, if the
SGML document instance is opened in, say, Adept Editor, the source of the
text inset is the SGML fragment file, not the FM+SGML text inset file used
when the same SGML document instance is opened in FM+SGML. Therefore, a
discrepancy could exist between the version of the SGML document instance
opened in FM+SGML and the same version of that document instance opened in
Adept. The discrepancy will occur if the SGML fragment is edited in Adept,
or if the corresponding text inset is edited in the FM+SGML text inset file.

And that, of course, defeats the whole concept of what entities are used
for, namely that there is only one version of each entity, and that version
will be used regardless of what software opens an SGML document instance
containing such entities.
===========================================================================
>As you point out, the user must avoid undeclared nested text insets.
>  If you declare SGMLFragment in your EDD, you can use any
>general rule/inclusions/exclusions that are appropriate to your
>situation; <ANY> is merely the general rule used on import as a default.
========================================================================
But any such modification to the general rule would defeat the intended
purpose of the SGMLFragment element, namely that it is used to import any
SGML fragment, no matter what it's structure. Since FM+SGML allows the use
of only one element (which must have the name SGMLFragment) for this
purpose, it seems to me you're stuck with a general rule of <ANY>.
     ====================
     | 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
10044 Adams Ave. #208, Huntington Beach, CA 92646
---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.   **