[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?
Page 1 / 1
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?The original program had gotos wich I don't like and could only handle xml data with a limited size. I changed it, so it reads the xml data from a file.
In the zip-file you find the modified parser and a program wich uses the parser to display the xml data.
I hope this helps a bit.
Andr
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?The original program had gotos wich I don't like and could only handle xml data with a limited size. I changed it, so it reads the xml data from a file.
In the zip-file you find the modified parser and a program wich uses the parser to display the xml data.
I hope this helps a bit.
Andr
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I too had looked at the parser you mentioned but stayed away from the go to's and developed one from scratch. It doesn't handle anything more than simple tags, and I have some known limitations I have to resolve.
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I too had looked at the parser you mentioned but stayed away from the go to's and developed one from scratch. It doesn't handle anything more than simple tags, and I have some known limitations I have to resolve.
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?This links into the runtime quite easily is pretty straight forward. We have used it extensively in a production environment. Can take up allot of memory.
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?At this point it looks to me like the only method I can develop for processing the parsed information is to code specific tag names into a program and develop individual routines for the logic associated with each. I had hoped to control this more externally, possibly within the dtd? My concern is, any changes the vendor makes to the dtd is going to require hard coded program modification, which makes every version of the program specific to a version of dtd.
The particular xml files I'm receiving in this example have hundreds of tags/attributes, most of which are duplicated within and below other common tag names.
Does this sound like the usual case? Am I trying to make life unrealistically simple?
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?At this point it looks to me like the only method I can develop for processing the parsed information is to code specific tag names into a program and develop individual routines for the logic associated with each. I had hoped to control this more externally, possibly within the dtd? My concern is, any changes the vendor makes to the dtd is going to require hard coded program modification, which makes every version of the program specific to a version of dtd.
The particular xml files I'm receiving in this example have hundreds of tags/attributes, most of which are duplicated within and below other common tag names.
Does this sound like the usual case? Am I trying to make life unrealistically simple?
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?Here is something of COBOL/XML faq, read on:
Q. Should I expect to see XML in a production environment?
A. Short answer: Yes
Long Answer: depends. If you are working on financial/accounting app with B2B exchange, it is only a matter of time before you run into some form of XML, either a propietary xml document standard (with dtd or schema) or standard XML/EDI.
If you don't have B2B requriements, but have html requirments, XML is still useful to export COBOL data for processing for HTML formatting. There are a lot of tools (espeically XSLT) which are useful for presenting XML on web pages.
Q. Is XML going to replace tradional file storage systems (vision/sql).
A. Short answer: No
Long Answer: Not in the near future. XML hype reached its peak around 2000-2001. A lot of pundits started talking about xml being a data panacea. A lot of big companies like Oracle and Microsoft got bit by the 'xml bug' and promised XML only database solutions around this time. To date nothing (except a transional system in the form of .net) groundbreaking has shipped.
The reality is there are a lot of unresolved tehnical issues surrounding xml only database repositories. More importantly, relational systems are serving the needs of most business applications just fine. XML does have strong inroads in EDI and in HTML brokering, as stated above.
Q: What is the difference between SAX and DOM?
SAX parsers (like expat) are simple 'scanning' processors that utilize user-constructed callbacks to pass over the xml document. Except for the simples of tasks, using these processers is programming intensive. The primary advantages of these processers are speed and low memory consumption.
DOM processers provide a much richer API for manipulating and dealing with XML documents. The document is realized as a tree and can be manipulated as such. The disadvantage of DOM is that the entire document has to be loaded in memory (with a lot of overhead) making it unsuitable for some applications.
Q. What is the right parser for me?
A. Short Answer: Xerces, expat, or Extend 6
A. Long answer: expat is well known as a fast and simple processor. If you have complex requirements, check out Xerces, which is run by the Apache follks and IBM, which is a very high quality XML SAX.DOM processor. It is cross platform and you will probably have to compile it, and is also written in C , not C. Also, the provide Xalan, which is a XSLT processor which is very fast and powerful.
If you have very low reqirements or would perfer to use C over C , or are looking for a simpler integration path with AcuCobol, you mat have to use expat, although their XML implementation (in Extend 6) is problably a superior (and easier) choce.
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?Here is something of COBOL/XML faq, read on:
Q. Should I expect to see XML in a production environment?
A. Short answer: Yes
Long Answer: depends. If you are working on financial/accounting app with B2B exchange, it is only a matter of time before you run into some form of XML, either a propietary xml document standard (with dtd or schema) or standard XML/EDI.
If you don't have B2B requriements, but have html requirments, XML is still useful to export COBOL data for processing for HTML formatting. There are a lot of tools (espeically XSLT) which are useful for presenting XML on web pages.
Q. Is XML going to replace tradional file storage systems (vision/sql).
A. Short answer: No
Long Answer: Not in the near future. XML hype reached its peak around 2000-2001. A lot of pundits started talking about xml being a data panacea. A lot of big companies like Oracle and Microsoft got bit by the 'xml bug' and promised XML only database solutions around this time. To date nothing (except a transional system in the form of .net) groundbreaking has shipped.
The reality is there are a lot of unresolved tehnical issues surrounding xml only database repositories. More importantly, relational systems are serving the needs of most business applications just fine. XML does have strong inroads in EDI and in HTML brokering, as stated above.
Q: What is the difference between SAX and DOM?
SAX parsers (like expat) are simple 'scanning' processors that utilize user-constructed callbacks to pass over the xml document. Except for the simples of tasks, using these processers is programming intensive. The primary advantages of these processers are speed and low memory consumption.
DOM processers provide a much richer API for manipulating and dealing with XML documents. The document is realized as a tree and can be manipulated as such. The disadvantage of DOM is that the entire document has to be loaded in memory (with a lot of overhead) making it unsuitable for some applications.
Q. What is the right parser for me?
A. Short Answer: Xerces, expat, or Extend 6
A. Long answer: expat is well known as a fast and simple processor. If you have complex requirements, check out Xerces, which is run by the Apache follks and IBM, which is a very high quality XML SAX.DOM processor. It is cross platform and you will probably have to compile it, and is also written in C , not C. Also, the provide Xalan, which is a XSLT processor which is very fast and powerful.
If you have very low reqirements or would perfer to use C over C , or are looking for a simpler integration path with AcuCobol, you mat have to use expat, although their XML implementation (in Extend 6) is problably a superior (and easier) choce.
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I've been able to link expat into the runtime and create callback routines to process it. What I'm struggling with at this point is my attempt to put the information into some readily accessable storage place, such as a Vision data file.
My reason for doing this is to be able to process any number of very different XML files but keep a fairly standard input procedure to actually handle the business logic of what to do with the information.
What it's coming down to looks like I'm going to have to include specific business logic in the code for tags to do specific things as the xml file is being parsed. Something I hate to do, but it looks like having a single parser process is not going to be attainable.
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I strongly advise against writing advanced processing routines in COBOL (I noticed after my last post it is built upon the expal XML processor). In other words, it is generally not a good idea to write processing routines for XML documents in a compiled language like COBOL, C, etc. because:
1. Its a complex solution to a simple job
2. Expect XML document structures to change frequently and without warning
3. C and COBOL are poor text processing languages
4. You are avoiding the inevitable
Basically, its like this. SAX based XML procesing is appropriate when your data 'structure' (i.e. organization and layout) is generated by some non XML source. In other words, you dump your files to an xml structure and then read them back in with expat. Usually, when sending data elsewhere, it is processed (transformed) at least once before arriving in destination data repository.
If your docuemnts are based on external requriements, or any type of tree layout, your can forget relying on 100% expat/cobol based solution. Its simply too much programming.
DOM was created to help traditional languages deal with complicated documents. Unfortunately for you, your options working with DOM in a strict cobol environment are pretty limited.
XSLT is the answer. XSLT is an xslt data transformation service that transforms xml from one dtd/schema to another. A typical b2b data migration path is:
RDMBS -> XML -> XSLT -> INTERNET -> XSLT -> RDBMS
XSLT transforms are a much smarter and easier way manipulating xml data from one type to another. Why bother jumping through hoops using COBOL to generate/parse nexted structures when xslt can do it for you?
There are a couple of different ways to get into XSLT: Xalan, the companion xslt parser to xerces (your previous objections notwithstanding), php's built in xslt processor, the microsoft XSLT processor.
If you are using windows, download the evaluation for xml spy which can do xml transforms and has a debugger to help you get started. In the long run, you need to settle on a command line based version, either php or xalan probably. If you have trouble with them, the web and usenet are excellent resources.
I understand the position you are in. I suggest spending a week or two and jumping in with both feet and learn how to deal with xml in a production environment. The time you spend doing that will be a better investment in yourself than in programming a COBOL program to parse the documents (and has better long term viability). The goal is to preprocess your xml data so that it is virtually a straight copy from a flat xml file to your cobol files. If you are feeling adventurous try setting up an .xsd schema to prevalidate your doucments incoming and outgoing (or use the schema/dtd supplied by the 3rd party). Trust me, at some point the light will click on and you will get bitten by the xml bug!
My .02$.
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I strongly advise against writing advanced processing routines in COBOL (I noticed after my last post it is built upon the expal XML processor). In other words, it is generally not a good idea to write processing routines for XML documents in a compiled language like COBOL, C, etc. because:
1. Its a complex solution to a simple job
2. Expect XML document structures to change frequently and without warning
3. C and COBOL are poor text processing languages
4. You are avoiding the inevitable
Basically, its like this. SAX based XML procesing is appropriate when your data 'structure' (i.e. organization and layout) is generated by some non XML source. In other words, you dump your files to an xml structure and then read them back in with expat. Usually, when sending data elsewhere, it is processed (transformed) at least once before arriving in destination data repository.
If your docuemnts are based on external requriements, or any type of tree layout, your can forget relying on 100% expat/cobol based solution. Its simply too much programming.
DOM was created to help traditional languages deal with complicated documents. Unfortunately for you, your options working with DOM in a strict cobol environment are pretty limited.
XSLT is the answer. XSLT is an xslt data transformation service that transforms xml from one dtd/schema to another. A typical b2b data migration path is:
RDMBS -> XML -> XSLT -> INTERNET -> XSLT -> RDBMS
XSLT transforms are a much smarter and easier way manipulating xml data from one type to another. Why bother jumping through hoops using COBOL to generate/parse nexted structures when xslt can do it for you?
There are a couple of different ways to get into XSLT: Xalan, the companion xslt parser to xerces (your previous objections notwithstanding), php's built in xslt processor, the microsoft XSLT processor.
If you are using windows, download the evaluation for xml spy which can do xml transforms and has a debugger to help you get started. In the long run, you need to settle on a command line based version, either php or xalan probably. If you have trouble with them, the web and usenet are excellent resources.
I understand the position you are in. I suggest spending a week or two and jumping in with both feet and learn how to deal with xml in a production environment. The time you spend doing that will be a better investment in yourself than in programming a COBOL program to parse the documents (and has better long term viability). The goal is to preprocess your xml data so that it is virtually a straight copy from a flat xml file to your cobol files. If you are feeling adventurous try setting up an .xsd schema to prevalidate your doucments incoming and outgoing (or use the schema/dtd supplied by the 3rd party). Trust me, at some point the light will click on and you will get bitten by the xml bug!
My .02$.
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I've been able to link expat into the runtime and create callback routines to process it. What I'm struggling with at this point is my attempt to put the information into some readily accessable storage place, such as a Vision data file.
My reason for doing this is to be able to process any number of very different XML files but keep a fairly standard input procedure to actually handle the business logic of what to do with the information.
What it's coming down to looks like I'm going to have to include specific business logic in the code for tags to do specific things as the xml file is being parsed. Something I hate to do, but it looks like having a single parser process is not going to be attainable.
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I've been able to link expat into the runtime and create callback routines to process it. What I'm struggling with at this point is my attempt to put the information into some readily accessable storage place, such as a Vision data file.
My reason for doing this is to be able to process any number of very different XML files but keep a fairly standard input procedure to actually handle the business logic of what to do with the information.
What it's coming down to looks like I'm going to have to include specific business logic in the code for tags to do specific things as the xml file is being parsed. Something I hate to do, but it looks like having a single parser process is not going to be attainable.
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?I'll check it out, I have already installed Xalan on our system while I was attempting to check out Xerces. I'm completely new to xsl processing but it sounds like it might be just what I need.
I've gone from a parser written in Acucobol to Expat to a combination and back again. Again, thanks for the information.
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?Good!
Learning XSLT is the first step. It will seem quite wierd at first, but is actually quite simple and elegant. Once you get the hanf of it, it will be a huge time saver.
Xalan and Xerces are the source distributions for the XSLT and XML processor. You are interested in niether the source nor the provided API. In fact, IIRC, you may not even have to compile (if you are using windows) because they provide (or at least they did provide) the binaries. These binaries may or may not requrie modification (i.e. editing the source and recompiling) to get them to do precisely what you want them to do.
Use Xalan to:
Convert outgoing xml (generated by Extent 6 ) to alternative form.
Convert incoming xml (generated by 3rd party ) to your internal structure for import.
Use Xerces to:
Test xml data, incoming or outgoing, vs a dtd/schema. Unlike expat, xerces will also do dtd scema validation. This is optional, but I suggest becoming comforatable using Xerces anyways. If Xerces can parse your documents without returning an error (with extended validation on), you are ok.
Ideally, xml transforms would be executed from command line. For example, (i just made these calls up, but expect to use something like them)
xln incoming.xml mytransform.xsl import.xml
It might instead work with stdin/stdout, for example
xln -t mytransform.sl import.xml
xerces would be very simple, running:
xerces incoming.xml
would parse the document. xsd schemas are explicitly referred to from within the xml document itself.
Its been a while for me, but the provide alot of examples of how to use them including some sample programs.
Good luck!
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?Good!
Learning XSLT is the first step. It will seem quite wierd at first, but is actually quite simple and elegant. Once you get the hanf of it, it will be a huge time saver.
Xalan and Xerces are the source distributions for the XSLT and XML processor. You are interested in niether the source nor the provided API. In fact, IIRC, you may not even have to compile (if you are using windows) because they provide (or at least they did provide) the binaries. These binaries may or may not requrie modification (i.e. editing the source and recompiling) to get them to do precisely what you want them to do.
Use Xalan to:
Convert outgoing xml (generated by Extent 6 ) to alternative form.
Convert incoming xml (generated by 3rd party ) to your internal structure for import.
Use Xerces to:
Test xml data, incoming or outgoing, vs a dtd/schema. Unlike expat, xerces will also do dtd scema validation. This is optional, but I suggest becoming comforatable using Xerces anyways. If Xerces can parse your documents without returning an error (with extended validation on), you are ok.
Ideally, xml transforms would be executed from command line. For example, (i just made these calls up, but expect to use something like them)
xln incoming.xml mytransform.xsl import.xml
It might instead work with stdin/stdout, for example
xln -t mytransform.sl import.xml
xerces would be very simple, running:
xerces incoming.xml
would parse the document. xsd schemas are explicitly referred to from within the xml document itself.
Its been a while for me, but the provide alot of examples of how to use them including some sample programs.
Good luck!
Merlin
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?As long as I don't have to modify/code anything I think I'm capable of building the binaries with make. Regardless, I'll cross that bridge when I get there, I'm just happy to have a brighter direction to head in!
Brad
[Migrated content. Thread originally posted on 21 February 2003]
Has anyone had to handle XML to date? I realize that there is a new capability coming with 6.0 to handle XML, but has anyone had any experience with it prior to that?As long as I don't have to modify/code anything I think I'm capable of building the binaries with make. Regardless, I'll cross that bridge when I get there, I'm just happy to have a brighter direction to head in!
Brad
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
