xml:space in document vs in element definitions

[bbbbbbbberg]

I'm testing XML/XHTML import in FrameMaker 2015.

If I use xml:space in my document, then FM2015 recognizes this and uses the correct spacing (a big improvement over the old version I've been using!).

But if I set my element definitions to automatically add an xml:space attribute, the white space is not preserved. I can tell that my definitions are getting applied because it applies the correct styles, and when I look in Structure View, I can see that xml:space is indeed set to preserve... but the spaces aren't correct.

Is there any way I can get FrameMaker to automatically recognize certain types of elements and preserve the whitespace, or do I need to explicitly set xml:preserve every single time I want to preserve spacing?

[Russ Ward]

bbbbbbbbbbbbbbbbbbbbbbbbbb, did you read this recent thread yet? I don't know if it answers your question but it seems related.

where should i place the 'xml:space = preserve'

Russ

[bbbbbbbberg]

I've read it. It doesn't answer my question.

[Lynne A. Price]

bbbbbbbberg,

    What do you mean by "if I set my element definitions to automatically add an xml:space attribute, the white space is not preserved."? Do you mean element definitions in your EDD, or element declarations in a DTD? And what do you mean by automatically adding an xml:space attribute? Specifying a default value?

   I haven't tested all the combinations, but I'm pretty sure that FM uses the value of xml:space in an XML document to determine how to interpret white space wile it is importing the XML document into FM. It uses the value of xml:space within FM only to be able to write it back out when you save the document as XML. Thus, if your XML document does not have an xml:space attribute but your EDD defines one with a default value of "preserve", once an element is imported into FM, it will have the attribute (with no value specified), but the default value will not affect the way whitespace is treated during import.

  On the other hand, if you are using a DTD, and the DTD includes declarations such as

    <!ATTLIST x xml:space (default| preserve) "preserve">

then the attribute value is available while the document is being imported and all <x> elements will import with preserved whitespace.

  Are you using xml:space because you want to use it with XML tools other than FM? Or are you just trying to get content with significant spaces into FM?

         --Lynne

[bbbbbbbberg]

At this point I'm just trying to get FM to recognize when spaces are significant.

By "element definitions" I meant definitions in the EDD. I was trying to set xml:space to preserve by default on types of elements where spaces should be significant.

I do have a DTD though (as my structured app is adapted from the built-in XHTML app) and when I look, I see this:

<!ELEMENT pre %pre.content;>

<!ATTLIST pre

  %attrs;

  width       %Number;      #IMPLIED

  xmlspace   (preserve)    #FIXED 'preserve'

  >

I tried adding a colon so it reads xml:space preserve, but that didn't seem to fix it.

[Lynne A. Price]

bbbbbbbberg,

    You definitely want the colon. And I have tested

        xml:space   (preserve)    #FIXED 'preserve'

and it does successively preserve space.

   The XHTML uses a custom client which I believe predates support of xml:space. If you are using it, it may be ignoring the xml:space attribute. I'm not sure what the client does and if you need it.

          --Lynne

[bbbbbbbberg]

Then maybe the problem is the XHTML custom client... I'll investigate more tomorrow, thanks.

[Lynne A. Price · Accepted solution]

The client source code is provided. Glancing through its comments, it seems to concentrate on converting links, table properties, and graphic properties from FM's default XML representation to XHTML. You may want at least some of it. Much of it could be done with XSLT instead of the FDK.

   --Lynne

[bbbbbbbberg]

I got it working! Not with a DTD, though. I'm not convinced that would work.

Anyway, I noticed that it seemed to be important which view I initially opened the file in. So if I initially opened it in XML view then all the spacing would be intact when viewed in XML view (but not in WYSIWYG view)... but if I initially open the file in WYSIWYG view then the spacing won't be right in either view.

This told me that the spaces were making it to FM but FM was stripping them out, so I wrote some pre-processor XSL to add xml:space="preserve" when needed, and that did the trick.

Thanks again 

[Lynne A. Price]

bbbbbbbberg,

    I have a simple test case in which xml:space="preserve" works when using a DTD. Furthermore, I get the same results whether I open the file in WYSIWYG or XML view and can go back and forth with no change.

   Do you happen to have a  r/w rule that interferes with the attribute, in particular:

      reader line break is forced return;

   The DTD I am using is:

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT body (p | pre)+ >

<!ELEMENT p (#PCDATA)>

<!ELEMENT pre (#PCDATA) >

<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

and the document is:

<body>

<p>aaa   bbb ccc

ddd</p>

<pre>aaa   bbb ccc

ddd</pre>

</body>

where there are three spaces after "aaa" in both places and a tab after "bbb".

The results are the same if I explicitly set the attribute n the <pre> start-tag.

--Lynne

[bbbbbbbberg]

I do have a "preserve line breaks" r/w rule, but when I remove it, that doesn't fix the spacing; I just don't get line breaks either.

Anyway, it looks like I need to use XSL anyway for other reasons, so it's no big deal to have the XSL add an xsl:space="preserve" while I'm at it.

[bbbbbbbberg]

Though on reflection I'm not entirely convinced that it's loading my updated DTD. (I've never had trouble getting it to load my updated element definitions.)