It's fairly natural to expect that you could use one piece of XML data in multiple places in an InDesign layout—but that's not at all the way that InDesign works. Once you've imported XML, there is a one-to-one correspondence between the elements in the Structure view and their expression in the layout. If you want an element to appear multiple times, you've got to duplicate the element for each appearance on a document page. (Obviously, you can get around this in some cases by placing the XML element on a master page.)
As the quote above states, the expectation is that you import one XML file to fill one content area (text flow) in your InDesign document. This is contradictory to the spirit of XML, which is all about reuse of content in multiple documents and in multiple ways. For example, you might want a standard warning or copyright or other block of content to appear in many places in a single document of a set of documents collected as a book. From the XML file, you cannot drag the same piece of structure into different locations in a single InDesign document.
InDesign CS2 XML export controls are more limited than those in InDesign CS3. CS2 does not have the Remap Break, Whitespace and Special Characters option. As a consequence, the XML that you generate from InDesign CS2 may contain characters used in publishing applications that are problematic in XML processing. Chief of these are the characters that make paragraph and manual line breaks in the text layout. XML doesn't use these types of characters, and depending on the processes you run after exporting XML from InDesign, you may have to clean up the XML to remove these types of characters.
□ Course offerings subject to change. Please check the web site for current course offerings.□
Unwanted characters (square) in XML exported form InDesign CS2
Some typographic controls may generate characters even in CS3 that are not XML-compatible. Adobe warns about this in the Help section about exporting XML: "Not all characters are supported in XML (such as the Automatic Page Number character). InDesign warns you if it cannot include a character in the XML file."
Related to the "bad characters" export problem above is the issue of imported XML that might contain tabs, spaces, and line breaks. Often this is seen in applications that "pretty print" XML files with indents and coloring to make them easier to read. For example, I use XML Spy by Altova. When the pretty-printed XML created in XML Spy is used for import, it creates unwanted effects in the layout.
To get a clean import, it is sometimes necessary to edit the text in a text editor to remove the tabs and spaces, play with the import dialog whitespace controls (Do not import contents of whitespace only elements in CS3), or to run an XSL transformation to remove line endings and tabs from the XML (in CS2) before importing it into InDesign.
Are you missing a required attribute? Have you forgotten to put a required element in your structure? The validation window at the bottom of the structure pane will tell you the sad story of your incompetence with the DTD, but the suggestions it offers won't always tell you enough about fixing the problem—see the section on Validating XML in InDesign for more information.
Several times when I had a DTD included in the XML that I was exporting, and checked the box to include the DTD declaration on export, I saw a message that the XML I was exporting was not going to be valid using the DTD. It seemed to me at the time that the message was bogus, as I had validated the content with the DTD before export. I opened the exported content in XML Spy to check it, and found that there was some kind of invisible (line break) character in the XML between elements. When I switched to EditPlus and looked at the same file, I saw square box characters in these places in the XML file. I had to do a search and replace on that character to get an XML file that would validate in XML Spy. This is related to the issue described in the topic "Bad characters."
It seemed to me that the most likely times to make InDesign crash were if I tried to get too fancy with my XSLT. I am accustomed to being able to sort, filter, wrap and unwrap elements, make substring operations on text in elements, and other tricks of the XSL trade. If I used these types of functions in XSLT that I was using when importing or exporting XML with InDesign, sometimes it didn't work, and sometimes it froze the application. See Advanced Topics: Transforming XML with XSL. My recommendation, if you need to do a lot of fancy manipulation of your XML, would be to use XSLT as a pre- or post-processing step external to InDesign.