I have come across an issue while migrating an RM/Cobol application using XML Extensions from v11 to v12. Please allow me to ask for advice, please.
As I develop XML applications, I follow these basic steps:
- I develop a basic cobol program including the data structure used for the XML
-
I use the slicesy utility to create an XSD, rename the XSD to {whatever}SAVE.xsd, and delete XSL and XTL
- I used Stylus Studio to recreate a style sheet using the XSD created by the slicesy utility and a sample XML document in the format I'm having to deal with
I like using Stylus Studio to create style sheets because I don't like typing the XSLT by hand. I make too many mistakes and I find it easier to map elements using Stylus Studio and adding simple XSLT statements (like xsl:if) if/when necessary.
It appears the XSD created by the slicesy utility does not include the "root" element using v12, and there is not a switch to pass into the slicesy utility to force the slicesy utility to create the "root" element. Douglas P with Micro Focus SupportLine confirmed that is true.
One alternative would be to create a "debug" document from the data-structure within the cobol program using an "XML EXPORT" command, and use Stylus Studio to map the elements using the "debug" document as one of the source/target documents (instead of the XSD).
I really don't want to re-map one of the style sheets as it is quite complicated. I realize the application will work "as is", but any changes would require the style sheet to be corrected by hand. Ultimately, I would like to have the "root" element within the style sheet so I can use stylus studio and not have to re-map a style sheet using a "debug" document.
Can anyone share any advice?
#XMLExtensions#RMCOBOLFor the export side, why not allow the XSLT to adapt to the presence of a root element in a way that doesn't interfere too much with your normal coding style.
I am presuming that your coding style is essentially one template that uses match="/" plus some helper templates.
The following matches the document root element, and if that root element is named root it uses xsl:for-each to shift the context to the first (only) child node. Your normal template, the one that matches "/" now, becomes a called template.
If you use absolute XPath references in your main template (that is, XPath references that begin "/root/..."), you must change all such XPath references to be relative to the main context node. For example, consider the following COBOL data definition:
01 my-record-item.
02 a-group-item.
03 a-data-item pic x(4).
If you have XPath references such as "/root/my-record-item/a-group-item/a-data-item", you must now realize that root may not exist, and that your context node will be my-record-item. So, the modified XPath would be "a-group-item/a-data-item".
Here is the suggested mechanism:
<xsl:stylesheet version="1.0" xmlns:xsl="www.w3.org/.../Transform">
<xsl:template match="/">
<xsl:choose>
<xsl:when test="local-name(.) = 'root'">
<xsl:for-each select="*[1]">
<xsl:call-template name="myMainTemplate"/>
</xsl:for-each>
</xsl:when>
<xsl:otherwise>
<xsl:call-template name="myMainTemplate"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template name="myMainTemplate">
<!-- your 'normal' stylesheet here -->
</xsl:template>
</xsl:stylesheet>
I have come across an issue while migrating an RM/Cobol application using XML Extensions from v11 to v12. Please allow me to ask for advice, please.
As I develop XML applications, I follow these basic steps:
- I develop a basic cobol program including the data structure used for the XML
-
I use the slicesy utility to create an XSD, rename the XSD to {whatever}SAVE.xsd, and delete XSL and XTL
- I used Stylus Studio to recreate a style sheet using the XSD created by the slicesy utility and a sample XML document in the format I'm having to deal with
I like using Stylus Studio to create style sheets because I don't like typing the XSLT by hand. I make too many mistakes and I find it easier to map elements using Stylus Studio and adding simple XSLT statements (like xsl:if) if/when necessary.
It appears the XSD created by the slicesy utility does not include the "root" element using v12, and there is not a switch to pass into the slicesy utility to force the slicesy utility to create the "root" element. Douglas P with Micro Focus SupportLine confirmed that is true.
One alternative would be to create a "debug" document from the data-structure within the cobol program using an "XML EXPORT" command, and use Stylus Studio to map the elements using the "debug" document as one of the source/target documents (instead of the XSD).
I really don't want to re-map one of the style sheets as it is quite complicated. I realize the application will work "as is", but any changes would require the style sheet to be corrected by hand. Ultimately, I would like to have the "root" element within the style sheet so I can use stylus studio and not have to re-map a style sheet using a "debug" document.
Can anyone share any advice?
#XMLExtensions#RMCOBOLI use this call in my old programs.
MOVE 1 TO XML-Flags.
XML COMPATIBILITY MODE
XML-Flags
See Page 65 of the XML documentation, from PDF.
The XML COMPATIBILITY MODE statement allows version 12 XML Extensions to be
compatible with existing data and applications by inserting <root> as the top-level entry in a
document during an export operation. While versions of XML Extensions prior to version 12
required that <root> be the top-level element of a document, version 12 and later of XML
Extensions will tolerate either the presence or absence or the <root> element. The <root>
element (compatibility mode on) in version 12 is generally necessary only when external
stylesheets refer to the <root> element and the user does not wish to modify the stylesheets to
eliminate those references.
I have come across an issue while migrating an RM/Cobol application using XML Extensions from v11 to v12. Please allow me to ask for advice, please.
As I develop XML applications, I follow these basic steps:
- I develop a basic cobol program including the data structure used for the XML
-
I use the slicesy utility to create an XSD, rename the XSD to {whatever}SAVE.xsd, and delete XSL and XTL
- I used Stylus Studio to recreate a style sheet using the XSD created by the slicesy utility and a sample XML document in the format I'm having to deal with
I like using Stylus Studio to create style sheets because I don't like typing the XSLT by hand. I make too many mistakes and I find it easier to map elements using Stylus Studio and adding simple XSLT statements (like xsl:if) if/when necessary.
It appears the XSD created by the slicesy utility does not include the "root" element using v12, and there is not a switch to pass into the slicesy utility to force the slicesy utility to create the "root" element. Douglas P with Micro Focus SupportLine confirmed that is true.
One alternative would be to create a "debug" document from the data-structure within the cobol program using an "XML EXPORT" command, and use Stylus Studio to map the elements using the "debug" document as one of the source/target documents (instead of the XSD).
I really don't want to re-map one of the style sheets as it is quite complicated. I realize the application will work "as is", but any changes would require the style sheet to be corrected by hand. Ultimately, I would like to have the "root" element within the style sheet so I can use stylus studio and not have to re-map a style sheet using a "debug" document.
Can anyone share any advice?
#XMLExtensions#RMCOBOLHi, John.
I have never been a big fan of XML COMPATIBILITY MODE. My theory is that this is a user interface issue that belongs in the XSLT and not in the COBOL program. Also, XML COMPATIBILITY MODE has a global effect, so could cause problems for an unrelated export as a undesired side effect. I can make the change to the XSLT so that it operates correctly in either situation. And, in fact, if you have a lot of XSLT to change, the changes can be made using XSLT in a batch command (been there, done that).
But, as with many things, the choice to use compatibility mode is a tradeoff made in consideration of the installed base for the application (since all three of us on this thread are ISVs) and shop standards.
I have come across an issue while migrating an RM/Cobol application using XML Extensions from v11 to v12. Please allow me to ask for advice, please.
As I develop XML applications, I follow these basic steps:
- I develop a basic cobol program including the data structure used for the XML
-
I use the slicesy utility to create an XSD, rename the XSD to {whatever}SAVE.xsd, and delete XSL and XTL
- I used Stylus Studio to recreate a style sheet using the XSD created by the slicesy utility and a sample XML document in the format I'm having to deal with
I like using Stylus Studio to create style sheets because I don't like typing the XSLT by hand. I make too many mistakes and I find it easier to map elements using Stylus Studio and adding simple XSLT statements (like xsl:if) if/when necessary.
It appears the XSD created by the slicesy utility does not include the "root" element using v12, and there is not a switch to pass into the slicesy utility to force the slicesy utility to create the "root" element. Douglas P with Micro Focus SupportLine confirmed that is true.
One alternative would be to create a "debug" document from the data-structure within the cobol program using an "XML EXPORT" command, and use Stylus Studio to map the elements using the "debug" document as one of the source/target documents (instead of the XSD).
I really don't want to re-map one of the style sheets as it is quite complicated. I realize the application will work "as is", but any changes would require the style sheet to be corrected by hand. Ultimately, I would like to have the "root" element within the style sheet so I can use stylus studio and not have to re-map a style sheet using a "debug" document.
Can anyone share any advice?
#XMLExtensions#RMCOBOLHi Tom,
I did not realize that this option had a global effect. Thanks for the info. I have this in only a few programs for now so I will turn it off again after processing is completed.
At some point I will need to regenerate all my xml programs using slicexsy. So far I have had schema changes in only two programs so I have not needed to recompile.
Thanks, John
