Highlighted
Absent Member.
Absent Member.
1983 views

XML Method

Jump to solution

For Visual Cobol,

I've been trying to figure out which XML Method is the more "current" one.

I've seen one that uses XML as a Stream and defines it in the File Section.

and

I've also seen one that uses Working Storage and EXPORTS or GENERATES the XML from there.

Which is the more current method? So I don't waste my time learning an older/outdated method.

Thanks

Eric Boatman

0 Likes
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner
Knowledge Partner

RE: XML Method

Jump to solution

Hi, Eric.

Well, my bias in favor of XML Extensions is quite high, since I am an active RM/COBOL developer.  Effective use of XML Extensions requires learning a bit about XSLT, an XML based transformation language used to transform XML into XML (presumably changing its format), HTML or plain text (which would include, for example, JSON).

A key design principal taught (and all too often ignored) for decades is that you should separate data, business rules, and presentation in order to have the most maintainable and flexible application.  This principal applies to XML use, as well.  Let's consider data flowing out of the COBOL application.  What XML Extensions promotes is to export data and specify an XSLT transformation to do the work of getting the data into the correct form for the recipient of the data.  Changes imposed by the recipient on the format of the data, but not the data itself, are then accomplished outside the COBOL program.

As an example, consider those wonderful ACA compliance documents.  (I have already done ours!)  Do you think the IRS will happily keep accepting exactly the same document format year after year?  The last two years have proven that is not the case.  Yet the actual data is the same.  Many of the changes that you might anticipate (such as differences in XML namespace) are quite easily changed in XSLT.  Not so easy in COBOL trying to emulate XML.

Or consider being on the receiving end of XML based business-to-business documents, such as an XML purchase order.  You can arduously code every small tweek in COBOL, only to be back in the code over and over again when your business partners move to new versions, or you can use XSLT to normalize the incoming documents to a single form that you can import.  (Because, really, a purchase order coming into the typical application is not going to change the expected data too much.)

Where alternative approaches to XML output/input might be useful is in what I think of as database dumps - many repetitions of very shallow XML documents.

But for deep, rich documents, I suggest keeping COBOL in the data business, and use XML tooling to manipulate the formatting and presentation.


Tom Morrison
Consultant

View solution in original post

0 Likes
5 Replies
Highlighted
Knowledge Partner
Knowledge Partner

RE: XML Method

Jump to solution

A reasonable answer might be enhanced by understanding what your situation is.  Can you share what role XML plays in what you are trying to accomplish?


Tom Morrison
Consultant

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: XML Method

Jump to solution

Absolutely ... I'm currently working with our Web Developer on sending him data to populate/update our website.

Originally we used comma delimited files, but as I started to get used to Visual Cobol I realized that we could probably communicate better with XML.

I've gotten both Methods of XML to work, but I'm nervous that I'll get comfortable using one style, and in reality the other style would be better long term.

I'm also laying the groundwork for the ACA AIR (IRS XML Document for 1094-1095C), so I need the XML created to be an accurate representation of XML, and not a best guess.

And it occurred to me I could ask the community, and get some thoughts on it.

If I'm going to continue using XML for communication in-house and the outside world ... what method should I be using, to save me from headaches later.

Thanks for the responses.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

RE: XML Method

Jump to solution

Hi, Eric.

Well, my bias in favor of XML Extensions is quite high, since I am an active RM/COBOL developer.  Effective use of XML Extensions requires learning a bit about XSLT, an XML based transformation language used to transform XML into XML (presumably changing its format), HTML or plain text (which would include, for example, JSON).

A key design principal taught (and all too often ignored) for decades is that you should separate data, business rules, and presentation in order to have the most maintainable and flexible application.  This principal applies to XML use, as well.  Let's consider data flowing out of the COBOL application.  What XML Extensions promotes is to export data and specify an XSLT transformation to do the work of getting the data into the correct form for the recipient of the data.  Changes imposed by the recipient on the format of the data, but not the data itself, are then accomplished outside the COBOL program.

As an example, consider those wonderful ACA compliance documents.  (I have already done ours!)  Do you think the IRS will happily keep accepting exactly the same document format year after year?  The last two years have proven that is not the case.  Yet the actual data is the same.  Many of the changes that you might anticipate (such as differences in XML namespace) are quite easily changed in XSLT.  Not so easy in COBOL trying to emulate XML.

Or consider being on the receiving end of XML based business-to-business documents, such as an XML purchase order.  You can arduously code every small tweek in COBOL, only to be back in the code over and over again when your business partners move to new versions, or you can use XSLT to normalize the incoming documents to a single form that you can import.  (Because, really, a purchase order coming into the typical application is not going to change the expected data too much.)

Where alternative approaches to XML output/input might be useful is in what I think of as database dumps - many repetitions of very shallow XML documents.

But for deep, rich documents, I suggest keeping COBOL in the data business, and use XML tooling to manipulate the formatting and presentation.


Tom Morrison
Consultant

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: XML Method

Jump to solution

Thanks for your input!

That was the direction I was going, but wanted to get a second opinion, of sorts.

With communicating to the web side of things, I've already had to do some XSLT manipulation, so I'm comfortable there. I just wanted to make sure my choice would give me the most flexibility, which is the situation you described very well.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

RE: XML Method

Jump to solution

Happy to help.  I don't know what XSLT/XML editor you may be using.  I favor Stylus Studio, and have been using it for years.  It has a drag-and-drop mapping for XSLT that is reasonably good for creating stylesheets for documents such as the ACA.  You set up the input document on the leftof the window (either the XSD or an exemplar in XML) and the output document on the right (ditto) and most of the work can be done with mouse drags.

If you need XSLT assistance, I frequent the XML Forum on Tek-Tips where I specialize in answering questions about XSL.


Tom Morrison
Consultant

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.