encoding chartset for XMI export

[ngong]

When I export to XMI, the xml top line tells the encoding - it tells

Code: [Select]

<?xml version="1.0" encoding="utf-8"?>.
This is a contradiction when inspecting elements description. There, it uses windows-1252 - but in the 2-pass ampersant notation.
E.g.

Code: [Select]

<properties documentation="&amp;#228;&amp;#246;&amp;#252;&amp;#223;&amp;#196;&amp;#214;&amp;#220;&#xA;€&amp;#181;" for several German special characters.

What is the strategie behind this?

Why not simply use utf-8 for all characters - or use windows-1252 also in the xml top line? Either case the ampersant notation is problematic and should be avoided, imho. You nerver know how many pathes of transformations (e.g. xslt) of the XMI will follow. And the ampersant notation using windows-1252 while the xml top line tells utf-8 seems to me simply wrong.

[Eve]

The problem is that the value is specified in the database with html character references. If you look in the database you'll see "äöüßÄÖÜ
€µ"

This is specific to the rich text fields, so you won't see it for names etc.

XMI export/import doesn't know or care about this formatting. It just puts adds the string it was given, which means the & characters in the above end up being encoded too.

The question is, why is this a problem for you? Did you write a bad transform that didn't take this into account?

[qwerty]

Hehe, a non-EA issue. You have to dance on Bill Gates' feet. He (or his former company) are responsible for that kind of stuff.

q.

[Geert Bellekens]

Hehe, a non-EA issue. You have to dance on Bill Gates' feet. He (or his former company) are responsible for that kind of stuff.

q.

I'm not sure if Microsoft had anything to do with the fact that ea stores certain characters html encoded.
Pretty sure that is a Sparx decision.

Geert

[qwerty]

I was targeting the windoze code page. Though, that was defined before any UTF was present. But little attempt has ever been made to get away from that.

q.