Re: FM+SGML: Attribute Indicators in Object Format Rules

[Dan Emory <danemory@xxxxxxxxxxxx>]

Ahh. Now it all comes back to me.

Because of what I regard as a bug in FM+SGML, the only way to get the proper
behavior on both import and export, as well as when inserting a new
cross-reference in FM+SGML, you must, in the EDD and the DTD, wrap the
cross-reference element (let's call it DocumentRef) in a container element
(let's call it XREF), which has the choice-type cross-reference format
attribute (let's call it "Role"). The initial cross-reference format rules
for element DocumentRef would then have the form:
		If context is: XREF[Role = "DocExt"]
				Use cross-reference format: DocExt
			Else, if context is: XREF[Role = "ISBN"]
				Use cross-reference format: ISBN Title

Now, with this structure and format rules, you get the following behavior:

1. When you set the FM+SGML New Element Options to "Always Prompt for
Required Attributes", insertion of a new XREF element in an FM+SGML document
will cause the Attribute dialog to open, and you are prompted for a value in
the Role cross-reference format attribute. Upon setting a value for the Role
attribute, the child cross-reference element (DocumentRef) is autoinserted,
and the Cross-Reference dialog opens with the format-rule-specified
cross-reference format pre-selected.

2. When you export to SGML, the XREF element (with its Role attribute) and
the DocumentRef element are both exported.

3. When you import to FM+SGML an SGML document instance in which each
DocumentRef element is wrapped in an XREF element having the Role attribute,
the cross-reference text will be in the format specified by the Role
attribute in the XREF element. That is, the initial cross-reference format
rules for element DocumentRef will apply, because the XREF container, with
its Role attribute, will have been imported before the DocumentRef element.

I have interjected additional comments in Lynne Price's response below.
 
At 04:41 PM 5/4/99 -0700, Lynne A. Price wrote:
>Whoops, didn't mean to send a previous message in which I'd quoted Anthony's
>message without adding any comments of my own.
>
>Anthony,
>  Are you getting unresolved cross-references or cross-references that
>use a format named Undefined Cross-Reference? The former will occur
>if you do not have a read/write rule like:
>    attribute "Refid"
>    {
>      is fm attribute;
>      is fm property cross-reference id;
>    }
>
>  You also need r/w rules for the spaces and medial capital letters
>in some of your names:
>
>    element "DocReference" is fm cross-reference element "Doc Reference";
>    value "DocExt" is fm value "DocExt";
>    value "ISBN" is fm value "ISBN";
>
>  Even with these rules, the EDD segment you have sketched does not work.
>I had no luck with != rules either. There is a significant different between
>initial object format rules and text format rules. Text format rules are
>reapplied each time an element's context changes; initial object format
>rules are used only when an element is initially created.
==================================================================
Not true if the format-defining attribute is in a parent container element.
In that case, the initial object format rules (i.e., If Context is:) for the
child element will use the attribute value in the parent to determine the
format on import, as well as during the edition of an FM+SGML document.
===================================================================== 
>Objects are
>treated differently because their formatting tends to be much more
>subject to user control than is text--it is likely to be very annoying
>if a table or cross-reference format changes as the user edits surrounding
>material.
=====================================================================
Why, then, does FM+SGML provide initial format rules for such objects?
Moreover, if the object format is specified by format rules that use values
in a format attribute, context will not affect the formatting of those objects.
=======================================================================
>  In my tests of importing a cross-reference from SGML, it seems that
>an initial cross-reference format specified in an AllContextsRule is, in
>fact, applied during import, while one in a ContextRule is not. I suspect
>this result has to do with the order in which the cross-reference element
>is created and its attributes set.
=====================================================================
The use of AllContextRules would result in mis-translation, on import of the
proper cross-reference formats, and would eliminate the capability to
pre-select the proper format when inserting cross-references in FM+SGML
documents.
=======================================================================
>  In any case, your EDD sets the cross-reference format based on the value
>of the Role attribute. The cross-reference format names do not quite
>match the possible values of the Role attribute. Is it possible to change
either
>the format names or the values so that they are identical? If so, then the
>rule
>      attribute "role" is fm property cross-reference format;
>will handle import. You will need to change the EDD to remove the Role
attribute--
>this attribute will only be used in SGML.
===================================================================
The approach you describe above (converting attributes to properties and
eliminating such attributes from the EDD) would eliminate the advantages of
using initial format rules that are attribute-value-dependent for inserting
objects such as cross-references in FM+SGML documents.
=====================================================================
Clearly, it is a bug (or, to be more delicate, a feature deficiency) of
FM+SGML that it cannot use formatting attributes for objects in imported
SGML document instances to pre-select the format for those imported objects,
using the same EDD format rules used for initial object insertion in FM+SGML.

The only workaround that permits the successful use of such formatting
attributes in all three of the enumerated cases (i.e., editing in FM+SGML,
import, and export) described above is to use the solution I have outlined.
Since, however, that solution won't work with most pre-existing DTDs, the
current behavior of FM+SGML is, in my view, a serious deficiency that
urgently need correction.
==================================================================   
     ====================
     | 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.   **