Hallo,

ich habe das Problem, dass das Zeichen > nicht als Entity exportiert wird sondern als > in Klartext.
XML-Export-Encoding ist auf UTF-8 gestellt, in der DTD sind folgende Entity-Einträge definiert:

<!ENTITY nohyphen "[nohyphen]" >
<!ENTITY shy "[shy]" >
<!ENTITY amp "[amp]" >
<!ENTITY lt "[lt]" >
<!ENTITY gt "[gt]" >
<!ENTITY nbsp " " >
<!ENTITY tab "[tab]" >

In der Rul sind keine Übersetzungsregeln definiert.
Es werden alle oben aufgeführten Zeichen als Entity kodiert, die restlichen Zeichen sind UTF-8, so auch das >
Wie kann ich bewirken, dass auch dieses Zeichen Entity-kodiert wird.

MfG
Mario

Hallo nochmal,

nach einigen Tests habe ich zwar keine Lösung für mein o.g. Problem finden können, dafür ein anderes Problem gefunden:
Wenn ich die Deklarationen für "shy", "nbsp", "nohyphen" und "tab" entferne, werden beim XML-Export die Zeichen als UTF-8-Zeichen geschrieben, beim XML-Import dagegen in druckbare Zeichen gewandelt (shy zu -; nohyphen zu -; nbsp zu Leerzeichen; tab wird gelöscht).

Warum nutzt der FM10 beim Import nicht die gleichen Regeln wie beim Export?
Wie kann man dies abstellen?

Vielen Dank für Unterstützung!

MfG
Mario

Hi Mario,

eigentlich ist FrameMaker seit Version 8 recht gut in der Einhaltung von XMl-Standards. Zum Beispiel muss man sich entity-mäßig um fast nichts kümmern, also auf keinen Fall um <, >, &, und auch nicht um das geschützte Leerzeichen. Das wird als Byte &#xA0; ins XML geschrieben und auch korrekt interpretiert.

Sonderfall ist die Trennunterdrückung (nohyphen), denn die gibt es im Unicode-Standard einfach nicht, und die bedingte Trennung (shy), hier wird beim Import tatsächlich nicht korrekt gearbeitet. Da in meinen Umgebungen die Trennunterdrückung nicht verwendet wird, habe ich nur die Regeln für shy, in der DTD:

<!ENTITY softhyphen "&#xAD;">

In den R/W Rules:

entity "softhyphen" is fm char "\x04";

Und im XSL-Preprocessing eine Routine, die alle Zeichen \u00AD durch die Entität &softhyphen; ersetzt.

Analog könnte es mit nohyphen gehen, der FM-interne Code für dieses Zeichen ist \x05.

Schöne Grüße,

- Michael Müller-Hillebrand
--
Dokumentations-Technologie
Info & Blog: http://cap-studio.de/

Hallo Michael,

vielen Dank für die schnelle Antwort.
Ich wollte eigentlich ohne Konvertierung vor dem Iport und nach dem Export auskommen.
Wäre zu schön gewesen, einfach UTF-8-Daten in den FM rein und als solche auch wieder raus.
Nun gut, ich werde nun die betreffenden Zeichen umkonvertieren und es dann nochmal so testen.
Was mir aber sehr komisch vorkommt, ist das &gt;, welches weder als Entity noch als UTF-8 exportiert wird wobei es ja bei &lt; super funktioniert. Gibt es dafür evtl. einen Lösungsansatz.

MfG
Mario

Das Größerzeichen > muss in XML nicht als Entity geschrieben werden, das ist vollständig optional.

- Michael Müller-Hillebrand
--
Dokumentations-Technologie
Info & Blog: http://cap-studio.de/

Hallo Michael,

das ist korrekt. Doch laut w3-XML-Standard gibt es 5 Zeichen, welche kodiert sein sollten (&amp; &lt; &gt; &quot; &apos;). Wenn ich diesem entsprechen möchte, muss ich auch das &gt; kodiert liefern. Mich macht es nur immer wieder stutzig, warum es beim FM solch unerklärlichen und für mich oft nicht behebbare Fehlerchen gibt. Ich sollte dem FM doch beibringen können, welche Zeichen ich kodiert ausgegeben haben möchte. Wozu gibt es denn sonst Rule-Files, Deklarationen in DTDs usw.

MfG
Mario

Einfacher Test: Das XML-Ergebnis mit einem XML-Editor validieren. Wenn der nicht meckert, ist alles in Ordnung. Es ist wirklich egal, ob im Text &gt; oder > steht, beides bedeutet das Gleiche! Es ist also kein Fehler, es ist nur etwas, was ich nicht per Konfiguration ändern kann.

Im Standard steht »The right angle bracket (>) may be represented using the string " &gt; "«. Wenn ein Programm das "may" als "must" interpretiert, ist es nicht XML-konform. (http://www.w3.org/...xml-20081126/#syntax)

Es gibt eine im Standard genannte Ausnahme im Zusammenhang mit der String-Sequenz "]]>" und da patzt FrameMaker tatsächlich, da gibt es aber den Workaround die "]" als Entität auszugeben.

Über ein XSL-Postprocessing lässt sich das Wandeln der > zu &gt; auch erreichen, wenn es denn unbedingt sein soll.

- Michael Müller-Hillebrand
--
Dokumentations-Technologie
Info & Blog: http://cap-studio.de/

Vielen Dank für die Antworten.
Also komme ich um eine Konvertierung nicht rum – schade.
MfG
Mario