xmlEncodeName bug?

[Former Member]

Hi All,

Just wondering if this is supposed to be normal behaviour or a bug?

In my XSLT I am creating new XML elements with names defined as:

<xsl:variable name="ColumnName" select="java:com.sap.lhcommon.common.LHUtilFunctions.xmlEncodeName(string(.))"/>

where

. = <xsl:for-each select="xalan:distinct(/Rowsets/Rowset/Row/*)"

Now what I've noticed is that when I get passed column names such as DENSICT/M³ (so T/M³) is a unit of measurement the xmlEncodeName is correctly converting the special character / as _ but it is letting the superscript 3 through and obviously I'm getting illegal attribute name errors when trying to create an XML element with that particular name.

Now I can "hack" around this by using the stringreplace functions and looking for superscript 2 and 3 and replacing them but is this a bug that xmlEncodeName is letting through special characters that will create illegal XML node names (contrary to its help description? )

Regards,

Danny

Edited by: Danny Yee on Apr 23, 2010 10:01 AM

[Former Member]

Thanks Jeremy,

I'll raise an OSS to get the function fixed then.

As an aside that DENSICT/M^3 value is a value from a database query to our LIMS that returns rows with 1 row per analyte ID + value (with timestamps). The analyte code + unit of measurement are unique identifiers for a particular sample batch so I use a transform to transpose all the rows into a tabular format based on common timestamps and generate column names based on the different analytes + UOM combinations.

Not sure if I can use an alias but I checking when I create columns they are valid for XML element node names. I think users are able to enter unicode text for unit of measurements hence the sub/superscript issue.

Edited by: Danny Yee on Apr 27, 2010 3:18 AM

[jcgood25]

Two thoughts / questions.

1. Where does the DENSICT/M³ as a column name come from in the first place? If coming from a database query, then aliasing it in the query might be your best option.

2. I did a quick check on several versions, all doing the same thing you mention. I would encourage you to please log a support ticket/bug so that the function can be corrected to handle super/sub scripts also.