Re: Graphic Entities in FM+SGML 5.5

[Dan Emory <danemory@xxxxxxxxxxxx>]

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.   **