Re: Graphic Entities in FM+SGML 5.5

[Janice McConnell <jym@xxxxxxxxx>]

Dan,

The writing of absolute paths in entity declarations and the
"entity name is" rule not using the value of an fm attribute
are two different issues. I logged 2 bugs for you during the
beta cycle. Both were marked fixed, as I reported to you at
the time. How entities are handled was changed considerably
in version 5.5.x. This was in response to customer requests
to have entites round-trip through FM+SGML. As you are aware,
in version 5.1.x, general text entities are expanded on
import and the entity information is not retained. In version
5.5.x, entity references from the SGML import are written back on export.

The "entity name is" rule itself has not been changed.
However, the dual mapping of the entity attribute to a fm
attribute as well as an fm property is no longer allowed.
Thus, it is not possible to assign an entity name through the
use of an fm entity. Once a file is associated with an entity
name, that association is retained - whether the association
came from an SGML import or the creation of a FM+SGML
document which is then exported to SGML.

The author can name his entities by adding entity
declarations to the DTD before exporting to SGML. FM+SGML
creates entity names only for files that do not yet have
entity names associated with them through an entity
declaration. These new entity declarations are written in the
internal DTD subset of the exported SGML document. On import,
any entity declarations in the internal DTD subset of the
SGML document are stored in an EntityDeclaration table on a
reference page to be referenced on export as entities in the
external DTD are.

Yes, these changes do require changes in your 5.1.x
applications in order to run them on 5.5.x.

Janice

At 10:53 AM 3/23/99 -0700, you wrote:
   At 08:26 AM 3/23/99 -0500, Janice McConnell wrote:
   >Dan,
   >
   >Part of my previous message (8/15/97) is correct. Part is
not. Absolute
   >paths will not be written in entity declarations created by
   >FM+SGML - only the name of the file that is created by
   >FM+SGML or the name of the imported file if the file was imported.
   >
   >The "entity name is " rule allows you to name the base entity
   >name for entity declarations that FM+SGML writes for you.
   >Without such a rule, the software defaults to the name of the
   >element as the base. The name of the file that FM+SGML
   >creates for you is also based on the name of the element
   >unless you specify differently with the rule "export to file
   ><filename>". The value of the variable $(entity) will be the
   >default entity name or the entity name you specified with the
   >first rule I mentioned.
   ==================================================================
   During the 5.5 Beta phase, I passionately objected to this
change in how the
   "entity name is" rule worked, and gave ample reasons for
why it would create
   serious problems. Your 8/15/97 response that:
   ---------------------------------
   >These problems had been addressed for the shipping version.
   >Absolute pathnames will not be written for Entity
   >declarations, and use of the appropriate read/write rule
   >using the "$(entity)" variable should cause entity names to
   >be written using the value of the Entity attribute in the
   >FM+SGML document.
   ---------------------------------
   produced the following 8/15/97 response from me:
   -----------------------------------
      WHEW!
      Thanks for your prompt response. Hopefully, the b9a version of the
      Developer's Guide was also revised to reflect the correct
      behavior, as it was described in the 5.1.1 Developer's Guide.
   -----------------------------------
   Now I discover that the behavior is the same as I
discovered it to be during
   Beta testing in August of 1997, and apparently has not been fixed in
   subsequent versions of V5.5.x. Appalling.
   ======================================================================
   >Entity names will be maintained for entities which already
   >have declarations.
   ======================================================================
   By "maintained" I take it you only mean that, if I import
an SGML instance
   into FM+SGML, the entity names will be maintained when it
is re-exported to
   SGML.
   
   But if I'm originating and maintaining the doc in FM+SGML
and occasionally
   exporting it to SGML, those entity names will NOT be
maintained, and thus
   each time I export the doc, the base name of the entity
will stay the same,
   but the suffix will be incremented in both the SGML
declarations and the
   filenames, producing multiple copies of each graphic, with
no way to discern
   which ones no longer apply and should be deleted. That's
the way it worked
   in v5.1.x when the entity rule was used that way.
   
   It deprives authors of the V5.1.x capability to control
the names of graphic
   entities and their filenames so that, each time the doc
was exported to
   SGML, the entity name and the filename would remain the
same, which meant
   that the old graphic file was overwritten by the most
recent version of the
   same graphic, thereby avoiding multiple copies of each
graphic, each with
   different non-descriptive filenames.
   
   Whoever made this change apparently assumed that FM+SGML
would not be used
   to CREATE structured docs, but instead its sole purpose was to import
   existing SGML docs. In other words, all FM+SGML is good for is a print
   engine for SGML docs. By making the change in the way the
entity rule works,
   Adobe has made
   that a self-fulfilling prophecy.

==============================================================
============
   >The entity name is no longer connected to
   >an attribute in the FM+SGML document. Instead, it is mapped
   >to an entity property which is not available for edit by the
   >author but is preserved or created by the software. That is,
   >the entity attribute of the SGML document can no longer be
   >mapped to both the FM+SGML entity property and a FM+SGML attribute.
   =====================================================================
   So, if the EDD declares that a graphic container has an attribute
   named "entity", and the DTD declares the same attribute
name for the same
   purpose in the GI for that same element, neither value
gets written into the
   other on import or export?
   ======================================================================
   >Let me know if I have not explained this clearly.
   =========================================================
   All too clearly I'm sorry to say. What this means (among
many other things)
   is that structured docs produced with version 5.1.x that used the old
   version of the entity r/w rule are incompatible with 5.5.x.
   
   In and of itself, this new "feature" alone would
discourage many users from
   upgrading to V5.5, or even using FM+SGML at all to
originate structured
   documents.  
        ____________________
        | 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.   **