Re: sgml errors

["Lynne A. Price" <lprice@xxxxxxxxxxxx>]

At 09:56 AM 4/30/03 -0400, eric.dunn@ca.transport.bombardier.com wrote:
>FM+SGML (I'm using 5.5.6) assigns the entity name based on the: USERSTRING!

As does FM 7.0 (and I assume FM+SGML 6.0, although I've confined my testing
to 5.5.6 and 7.0). 

Which leaves the question of how the user string was set in your documents.
If you import SGML documents (or XML documents in 7.0), as you've noticed,
the user string of the imported object is set to the entity name--this is
how FM links up the graphic with entities declared in the DTD or entity
information saved on the entity declarations reference page. Do you have
any scripts or FDK clients that may have changed it? (By the way, you can
set the user string with a client; FM declares the entity if it does not
already exist.)

Meanwhile, earlier you reported:

>>>>
There is a R/W rule:
 element "Graphic" {
     is fm graphic element;
     attribute "entity" is fm attribute;
     attribute "file" is fm attribute;
     attribute "width" is fm attribute;
     attribute "height" is fm attribute;
} 
  
But the value of entity in all cases seems to be <no value>.
<<<<

Janice McConnell questioned this rule:

>>>>
 I think your problem is that you have "ruled" that both "entity" and "file" are fm attributes. Unless you have specified another attribute to be either the entity or file property, FM doesn't know where to get a name.
<<<<

I agree with Janice on this point. If you have no r/w rules
for attributes named "entity" or "file", when processing
a graphic element, FM interprets the former as the name of
an entity identifying the graphic file to be imported and
the latter as the name of such a file. A rule mapping
either SGML (or XML) attribute to a FrameMaker attribute
disassociates the attribute from this special processing;
the attribute simply becomes an attribute whose value is
preserved in both the SGML and FM views.

However, in an earlier message I had asked:

>>>>
 Have you mapped the value of an FM attribute to the SGML entity name
>>   with a rule such as
>>
>>   attribute "xyz" {
>>      is fm property entity;
>>      is fm attribute;
>>      }
-----------------------------------
<<<<

To which Janice had responded:

>>>>

I don't believe that "entity" can be both a property and an attribute as Lynne's example rule implies.
<<<<

In fact, it is possible (although not documented) that both file
and entity attributes be mapped to both FM attributes and properties.
Given the rule:

attribute "entity"
  {
     is fm property entity;
     is fm attribute;
  }

FM allows a user to create new graphic elements in the FM user
interface and specify their entity names by setting their FM
entity attributes. In particular, with this rule, on import, FM
uses the value of the entity attribute to find the file to be
imported. It does not set the entity attribute in the reslting
FM document. On export, however, FM uses any value of the
FM entity attribute as the entity name it exports to SGML or XML.
Thus, the user can specify meaningful entity names for new
graphics by setting this attribute in FM. Names of the form
graphic1, graphic2, ... (or a variation specified with an
entity name rule) are used only if the attribute is not set.
However, a name specified in the user string of an imported
graphic has priority over a name specified in an entity attribute.
Thus, FM uses the original entity name when exporting a graphic
that was originally imported from SGML or XML.


The rule:

attribute "file"
  {
     is fm property file;
     is fm attribute;
  }

is less useful. FM sets the FM attribute on import but ignores the
value on export. If the graphic element also has an entity attribute,
FM exports a value of the entity attribute but not the file attribute.
If there is no entity attribute, it exports a file attribute, but sets
that value to the name of the graphic file and ignores any value of
the FM attribute.

	--Lynne

Lynne A. Price
Text Structure Consulting, Inc.
Specializing in FrameMaker+SGML consulting and training
lprice@txstruct.com
http://www.txstruct.com
voice/fax: (510) 583-1505
cell phone: (510) 421-2284

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