At 03:04 PM 4/7/2006, Grinnell Larry-ELG001 wrote: >Changing attribute types: Frame 7.0 Structured Developer's guide states >that without a Read/Write rule, Frame changes all NMTOKENS attribute >types to Strings on import then changes all Strings attribute types to >CDATA types on export (pages 248-249). > >I need to ensure certain attribute values are NMTOKENS type on export >but I can't get the following argument (from page 425) to work in my R/W >rules: nmtokens attribute "Role" is fm Strings attribute;
Larry, If you are trying to ensure that the attribute values are valid name tokens, FM validation won't help. Thus, if you include a character in the value of a FM Strings attribute that is not permitted in an XML NMTOKEN attribute, the validation error will not be reported until you export the FM document to XML. Nor will FM attempt to correct the error. You could use the FDK either to validate the attribute as you edit, or to transform it. Given a rule of the form: xmldv attribute "attname" is fm fmtype attribute; FM is supposed to use xmldv when generating a DTD from an EDD and fmtype when generating an EDD from a DTD. Thus, you can have an XML NMTOKENS attribute correspond to a FM String attribute instead of the default Strings, or an XML CDATA attribute correspond to an FM unique-id attribute. The particular rule you have quoted: nmtokens attribute "Role" is fm Strings attribute ; should not change the default processing when creating an EDD from a DTD, since FM creates a Strings attribute from a NMTOKENS attribute without a rule. When creating a DTD from an EDD, though, the default is to create a CDATA attribute from a Strings attribute. Doing so ensures that all valid FM attribute values will correspond to valid XML attributes. However, it can prevent an accurate round-trip since when a CDATA attribute is mapped to a Strings attribute, the entire XML attribute value is treated as a single string. The above rule or the simpler form: nmtokens attribute "Role" is fm attribute ; should declare the XML attribute as NMTOKENS instead. However, I've been doing some testing with FM 7.2p158 on Windows. It reports a syntax error at the keyword nmtokens and nmtoken. Furthermore, other possible values of xmldv seem to have no effect on the resulting DTD. When creating an EDD from a DTD, all possible values of fmtype seem to be processed correctly except "string" which has no effect. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.com http://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284