I am involved in a project where I must parse dates from an XML document. The application uses RMCobol and XML Extensions to create/parse XML. The issue is the dates are in different formats within the received XML. I have no control over the incoming XML, nor can I ask the formatting to remain consistent. The integration partner sends the data as they send the data and it's up to us how to handle it.
Here are 2 examples of the dates within the XML:
<InvoiceDate>2014-08-01Z</InvoiceDate>
<PayTermsString>20140818</PayTermsString>
My only idea was to replace the non-numeric characters with a space, put the data together without spaces, then break the date apart as 4-year, 2-month, and 2-day. However, I don't trust the data coming from the integration partner and what I described won't work if the data comes in as 2-month, 2-day, 4-year.
My question:
Is there anything I can do within the parsing style sheet to ensure the incoming dates are in a consistent format?
#ParsingDateswithinXML#RMCOBOL#XMLExtensionsHello Russell.
In general, I try to solve these issues in the XSL being used to import or export the data. My philosophy is that the XSL is the place that negotiates the idiosyncrasies of the 'user interface' (which in this example is the idiosyncratic behavior of the integration partner).
First, the import side:
The InvoiceDate is in standard XML date format, in that it is yyyy-mm-dd along with the time zone indicator (Z). However, it is up to interpretation how you might convert the UTC date (Z indicates Universal Coordinated Time - UTC), typically by either choosing the first second of the day, or the last second of the day.
PayTermsString is a little different. I wonder if it will always be a date, or whether strings such as Net 30 might show up there too.
In practical perms, I create a template that will crunch the data in the XML node and normalize it to the desired date format for the COBOL program. There are a couple ways to invoke this template.
First, one can use the mode designator on the template definition:
<xsl:template match="*" mode="crunch_date">
...
<xsl:value-of select="output the normalized date string"/>
...
</xsl:template>
This template can then be invoked using xsl:apply-templates. For example, if my context is the parent of <InvoiceDate> I can invoke the template as follows:
<xsl:apply-templates select="InvoiceDate" mode="crunch_data"/>
Alternatively, one can use a named template and use <xsl:call-template> to invoke it. One can pass the string to be crunched as a parameter.
There are several XPath functions that can be helpful in converting dates. To name a few: contains(), translate(), substring(), substring-before(), substring-after(), string-length(). One trick I use is to translate "0123456789" to "0000000000" in a xsl:variable so that I can test to see if a string is numeric by testing only for zeros.
The export side is more straightforward, since you have the input totally under your control.
Final note: You probably have installed on your computer a very decent set of date/time translation XSL templates. In the BIS samples/common directory, you will find date handling templates at the end of soap_to_cobol.xsl and cobol_to_soap.xsl. The templates are designed to convert to/from standard XML datetime strings and typical COBOL datetime representations. These might be useful 'as is' or you might bend them to your needs.
Have fun, and good luck!
Tom Morrison
HCSS
