EnterpriseArchitect 2017.1.1 XML export file not well-formed

5 posts 0 new
Log in or register to post comments.

EnterpriseArchitect 2017.1.1 XML export file not well-formed

It seems that the raw XML generated by the export function is a bit invalid. Two issues identified so far:

1) The XML is declared to have UTF-16 encoding, but the produced XML is actually encoded in UTF-8. This causes issues with an external application which fails to parse the XML unless I change the encoding in the declaration to "UTF-8".

So far I have found out a workaround, by having EA to do a simple XSLT transformation identity copy, which outputs the entire contents but re-encodes it into UTF-8:

<xsl:output method="xml" version="1.0" encoding="UTF-8"/><xsl:template match="node() | @*">    <xsl:copy>        <xsl:apply-templates select="node() | @*" />    </xsl:copy></xsl:template>    

Is there a simpler way to change the default encoding declaration to be UTF-8 to match the actual encoding?


2) The namespace xmlns="www.qpr.com" is not a valid URL, since RFC 3986 mandates it to have the scheme prefix (like http://). So a valid version of this would be "http://www.qpr.com". In my use case this triggers a warning when parsing, but fortunately it doesn't prevent to parse it.

Is it possible to add the scheme prefix to the namespace URL?



Unfortunately it seems that the PD/EA has a bug in XML Export. Our Customer Care will create a bug documents for these.
Good thing that you have found workaround for the encoding. I guess that there could be a API Script workaround for the namespace issue: 
-first Export the XML with API command
-change/edit the exported file with VBscript commands 

Hi Jussi,

Could you send email of the issue to customercare@qpr.com ?

We can then answer to your email when the bug is fixed.

-Janne, QPR CC


Thank you for the response. Upon further investigation it turned out that the encoding issue was due to a bug in the validator I'm using. The encoding seems to be fine after all.

However, the namespace still should have the proper http:// scheme prefix in it as per the RFC, but it seems not all validators/parsers are bothered by it.