Re: XML data
On Apr 8, 7:38*am, Pavel Lepin <p.le...@ctncorp.com> wrote:
> Follow-ups to comp.text.xml
> Ted <r.ted.by...@rogers.com> wrote in
> > On Apr 7, 9:24*am, Jerry Stuckle <jstuck...@attglobal.net>
> > wrote:
> >> Ted wrote:
> >> > Is there a relatively painless option for processing
> >> > the XML file to parse it and place the data it contains
> >> > into the right records and columns?
> >> > I have managed to avoid parsing XML up till now
> >> > (parsing strings is one of the programming tasks I
> >> > dislike the most), but alas it has caught up to me and
> >> > I have to bear down on it and put together something
> >> > which will make processing XML less painful when I have
> >> > to do it. *:-(
> Writing a standard-compliant XML parser is no easy task. But
> there are very few reasons for you to want that, since XML
> parsers are readily available for pretty much every
> language and platform with a market share larger than a
> >> I doubt there's much you can do with MySQL itself unless
> >> it matches the XML produced by MySQL. *You'll probably
> >> have to use another language such as Perl or PHP - both
> >> of which have ways of working with XML files.
> > I know both and can work with either. *I have just
> > avoided, or ignored, development tools related to XML. *Do
> > you have a favourite Perl package for this?
> The URL for CPAN is <http://cpan.org/> I believe.
> XML::Simple is a common choice for a lightweight,
> easy-to-use XML parser among Perl programmers.
> Both PHP4 and PHP5 come with standard extensions capable of
> parsing XML: see DOM XML for PHP4 and DOM for PHP5. Both
> make a good effort at mapping W3C's DOM API to PHP.
> > My greatest strengths are in raw number crunching in
> > fortran and especially C++.
> For that matter, libxml2 and Xerces-C++ are two XML parsers
> commonly used with C++, if that happens to be your language
> of choice.
> > At present, the prospect of writing code to process XML
> > feels like being a fish out of water.
> There's absolutely no reason for you to process XML
> documents without using a canned parser. The whole point of
> canned parsers is allowing you to work with a DOM tree, SAX
> event stream or some other data model of XML Infoset.
> "...a Netscape engineer who shan't be named once passed a
> passed it back to C, killing 30..." --Blake Ross
Thanks pavel. I guess the principal thing is to learn to use the
tools I have (I have XML::Simple for Perl) I'll be doing this in
Perl, I think, since C++ would be over kill.
On the C++ and Java side, what would be handy is a library that will
create a vector of objects based on the contents of the XML file
received, or a utility that takes the contents of an XML file and puts
its data into th epersistence layer of a web app, perhaps using
Hibernate or Spring (neither of which have I had time to properly
One of my frustrations is that, no matter what programming language I
am using (which ncludes Java, along with C++, Perl, &c), I have to
create a suite of classes in the programming language, and then repeat
that effort in the database back end, and yet again when creating a
user interface, and now with XML source files, the object/class
definitions are repeated yet again in yet another form. What I would
dearly love to find is a tool that takes this information about
classes and their relationships, from any input, whether that input is
an XML file, a schema for a DB, or a suite of compilation units/source
code files for whatever language, and creates all the other forms it
requires (ideally letting me create the relevant UML diagram and
create the works from that. But I guess that is too utopian fo rthis
Re: XML data
> dearly love to find is a tool that takes this information about
> classes and their relationships, from any input, whether that input is
> an XML file, a schema for a DB, or a suite of compilation units/source
> code files for whatever language, and creates all the other forms it
> requires (ideally letting me create the relevant UML diagram and
> create the works from that. But I guess that is too utopian fo rthis
To avoid making this an N-squared problem, the usual solution is to pick
one core representation and write 2(N-1) conversions between it and the
others; you can then run two of those back-to-back to convert between
forms other than the core. Some implementations of this kind of system
have used XML as the core representation; others have used databases or
other programming structures.
The hard part is automating the construction of those conversion
routines. Websearch for the phrase "data binding" will find some tools
that have been written for that purpose, not all XML-related. The
problem is that the quirks of each possible representation tend to make
producing a _complete_ interoperable conversion environment more than
slightly painful; it may wind up needing enough manual assistance that
it's simpler just to hand-code the conversions in the first place.
|All times are GMT. The time now is 05:56 AM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.