XML reader/writer

Does anyone out there have any experience using XML Thunder
(http://www.canamsoftware.com/produc...nder/index.html) for creating
and/parsing XML documents?  What are your thoughts?  What are alternative
products?  We are on the mainframe but run VSE so Enterprise COBOL with all
of it's nifty XML stuff is not available.



---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

In article <c35aun$236nqv$1@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

> Does anyone out there have any experience using XML Thunder
> (http://www.canamsoftware.com/produc...nder/index.html) for creating
> and/parsing XML documents?  What are your thoughts?  What are alternative
> products?  We are on the mainframe but run VSE so Enterprise COBOL with al
l
> of it's nifty XML stuff is not available.

It is not a hard thing to hand roll your own XML parser.  It can be done
in Cobol, but if you have C available it is almost automagic.

Let me know if that is an option that might interest you.

Regards,

Joe

We are currently evaluating XML Thunder. It looks promising. The code it
generates is COBOL subprograms which we like. However, it generates a static
Linkage section (no copybook). I minor niggle that they say is being worked
on. We also needed pure ANSI 85 source generation that they have added. I
would say we are likely to purchase it.

Others in this realm? XMLBooster. Same basic premise as XMLThunder.
Generates copybooks rather than subprograms. Does not have a GUI for
specifying the mappings, only a special Meta Language that is specified in
XML, although it supposedly can do some initial generation based on actual
XML document instances. There is also a company named Maas that has
something but I did not pursue it much since it was very IBM centric (I've
got Unisys). We even engaged META Group and they didn't find much beyond
this list either although it is is a niche that seemingly isn't very big so
they could easily miss some offerings.

Douglas Gallant

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c35aun$236nqv$1@ID-184804.news.uni-berlin.de...
> Does anyone out there have any experience using XML Thunder
> (http://www.canamsoftware.com/produc...nder/index.html) for creating
> and/parsing XML documents?  What are your thoughts?  What are alternative
> products?  We are on the mainframe but run VSE so Enterprise COBOL with
all
> of it's nifty XML stuff is not available.
>
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO  USA

Hey, Joe.

No, we don't have C available.  But I am curious as to the 'thought' process
behind building an XML parser.  Are XML parsers basically generic or do you
build a new one for each XML structure?

Sorry if that question doesn't make sense, but I'm not sure how else to word
it..

Frank
 
In article <c35aun$236nqv$1@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

> Does anyone out there have any experience using XML Thunder
> (http://www.canamsoftware.com/produc...nder/index.html) for
creating
> and/parsing XML documents?  What are your thoughts?  What are alternative
> products?  We are on the mainframe but run VSE so Enterprise COBOL with
all
> of it's nifty XML stuff is not available.

It is not a hard thing to hand roll your own XML parser.  It can be done
in Cobol, but if you have C available it is almost automagic.

Let me know if that is an option that might interest you.

Regards,

Joe

Frank Swarbrick writes ...

>Hey, Joe.
>
>No, we don't have C available.  But I am curious as to the 'thought' proces
s
>behind building an XML parser.  Are XML parsers basically generic or do you
>build a new one for each XML structure?
>

Language gets in the way here. XML folks define various APIs for
generic XML parsers. The latest z/OS COBOL compiler includes
an XML PARSE statement that makes one of these APIs available
in native COBOL.

If you want to just scan XML in and extract the fields,
you can write a generic one in any language. However,
the difficulty is in direct proportion to how complete
coverage you want to give. For example, if you know
your incoming XML documents will never, ever have
entity references, your scanner / extracter can be
considerably simplified; similarly if you know you will
only see EBCDIC data, you can simplify your life.

That being said, such input XML is no longer official
XML but a subset, and that might not meet your needs
long term.


[snip]

Hope this helps.

Kind regards,


-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c39rev$24uh5d$1@ID-184804.news.uni-berlin.de...
> Hey, Joe.
>
> No, we don't have C available.  But I am curious as to the 'thought'
process
> behind building an XML parser.  Are XML parsers basically generic or do
you
> build a new one for each XML structure?

Depends if you want to parse XML "in general" or parse a specific XML
document.

Or more accurately, do you want something you can code once and use again,
or do you want to  code a new program for each new document?

While "generic" will be more expensive up front, it earns savings down the
road. But if you do not anticipate any new XML documents, it's economically
unwise to spend the extra time (money) to create something reusable.

Just like any other design decision.

MCM

Most of the process is very generic.  If you choose the SAX style parser
(Simple API for XML) then you have a very limited number of "events"*
that would get handed off to your "DocumentHandler" program/object.

The generic part of the parser would handle "reading" the xml and
ensuring it is well-formed and/or valid.  Then it would hand off a
copybook for each event to your customized document handler program that
must know what to do with the various events.

XML was designed with the idea that the parsers would be very easy to
write.  It has no special exceptions and very few rules.  A recursive
descent parser for xml can be thrown together from the publically
available grammer in a few days to a few ws.  But coding a recursive
descent parser in a non-recursive language like Cobol is quirky, not
impossible, just quirky.  A stack based language that supports recursion
(C, pascal, java, etc) would be a better choice.

I suppose it would be best to ask, what do you have available at your
site?




(The SAX events are, if memory serves, startDocument, endDocument,
startElement, endElement, characters, whitespace, processingInstruction,
resolveEntity.  SAX is the sequential, forward only style of parser, the
other is DOM, document object model, which builds an in-memory tree to
represent the document)



In article <c39rev$24uh5d$1@ID-184804.news.uni-berlin.de>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

> Hey, Joe.
>
> No, we don't have C available.  But I am curious as to the 'thought' proce
ss
> behind building an XML parser.  Are XML parsers basically generic or do yo
u
> build a new one for each XML structure?
>
> Sorry if that question doesn't make sense, but I'm not sure how else to wo
rd
> it..
>
> Frank
> 
> In article <c35aun$236nqv$1@ID-184804.news.uni-berlin.de>,
>  "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
> 
> creating 
> all 
>
> It is not a hard thing to hand roll your own XML parser.  It can be done
> in Cobol, but if you have C available it is almost automagic.
>
> Let me know if that is an option that might interest you.
>
> Regards,
>
> Joe
>
>

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:c35aun$236nqv$1@ID-184804.news.uni-berlin.de...
> Does anyone out there have any experience using XML Thunder
> (http://www.canamsoftware.com/produc...nder/index.html) for creating
> and/parsing XML documents?  What are your thoughts?  What are alternative
> products?  We are on the mainframe but run VSE so Enterprise COBOL with
all
> of it's nifty XML stuff is not available.

We have a tool that generates DTD-specific readers and writers for COBOL.
These are extremely fast, validate for free, and make the XML data available
in native COBOL fields.  Contact me for more details.


--
Ira D. Baxter, Ph.D., CTO   512-250-1018
Semantic Designs, Inc.      www.semdesigns.com





----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==--
--
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 News
groups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

Hi,

While it is true that XMLBooster uses its own XML-base meta-language to
specify the XML constructs to recognize, and how they should map to
COBOL data fields, it is shipped with a Swing based GUI that allows the
casual user to define these information in a totally controlled environment,
without having to memorize large numbers of XML elements and attributes.
Besides, XMLBooster provides translators from DTD's and schemas to this
meta-language, in addition to the ability to derive it from a set of XML
samples.

A lite version of the product is freely available at:
http://www.xmlbooster.com

Regards,
Deborah

"Douglas Gallant" <no@spam.net> wrote in message
news:GIt5c.30006$KB.1600@twister.nyroc.rr.com...
> We are currently evaluating XML Thunder. It looks promising. The code it
> generates is COBOL subprograms which we like. However, it generates a
static
> Linkage section (no copybook). I minor niggle that they say is being
worked
> on. We also needed pure ANSI 85 source generation that they have added. I
> would say we are likely to purchase it.
>
> Others in this realm? XMLBooster. Same basic premise as XMLThunder.
> Generates copybooks rather than subprograms. Does not have a GUI for
> specifying the mappings, only a special Meta Language that is specified in
> XML, although it supposedly can do some initial generation based on actual
> XML document instances. There is also a company named Maas that has
> something but I did not pursue it much since it was very IBM centric (I've
> got Unisys). We even engaged META Group and they didn't find much beyond
> this list either although it is is a niche that seemingly isn't very big
so
> they could easily miss some offerings.
>
> Douglas Gallant
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:c35aun$236nqv$1@ID-184804.news.uni-berlin.de... 
creating 
alternative 
> all 
>
>