Are there any VB6 compatible XML components out there?
AFN
manually. Does anyone know of any free (or paid) components or public
source code that will help me do the parsing and iteration through XML
values (and getting the XML data across the internet)? And are the one(s)
you might mention any good?
Joseph M. Ferris
Good is subjective, but the MSXML parser is free...
Seriously, it is not bad. I believe that IBM has a parser, as well, but
I have not used it. The parser will handle XPath expressions and has a
transport library for sending XML documents over http.
--Joseph
Bonj
>I don't want to do all the parsing work
> manually.
Then just use text files!
Bonj
> Seriously, it is not bad.
Wrong, it is very bad. :- XML is a poncey, unnecessarily complex, and
probably French, "technology". Why bother define a protocol for something
which simply pads the data you want to store? I must admit, I can see how it
is useful. But I can also see how text files are useful, and I can't see how
any sort of 'standard' for putting all the data in tags is going to make the
program that writes or uses the data any better. Thus, there IS no point in
XML files whatsoever. No offence, really - to either you or your great
software designed for reading these files - but the only question that
remains is (why?)
Was it invented by hard-disk manufacturers by any chance?
Frank Carr
news:%23B3kUnm...@TK2MSFTNGP12.phx.gbl...
> Wrong, it is very bad. :- XML is a poncey, unnecessarily complex, and
> probably French, "technology".
Ooooo....French....that's a big insult there. (LOL)
> I can't see how
> any sort of 'standard' for putting all the data in tags is going to make
the
> program that writes or uses the data any better. Thus, there IS no point
in
> XML files whatsoever. No offence, really - to either you or your great
> software designed for reading these files - but the only question that
> remains is (why?)
It is very helpful when it comes to passing data between different systems.
For example, where I work we have to send data to a number of different
vendors and service organizations. By having a defined standard that can be
checked and verified easily (XML Schemas) it makes it much easier than using
dozens of different proprietary formats like we did in the past. It also
allows for easier passing of hierarchical data than with plain text formats.
Another plus is formatting data for presentation using XSL.
Sure, it can be used to the point of overkill (a constant joke around our
office) but it has some very powerful uses. It's just a matter of picking
the right tool for the job.
--
Frank Carr
jfc...@msn.com
http://www15.brinkster.com/vbnotebook
Altman
normalized table. When I want to send data from a join of 2 or more tables
with a one to many relationship then it gets very difficult for a plain text
file unless you split it into 2 files. Then you have redundant data to link
the 2, overhead on opening and closing the files, and alot of unneeded
complexity in reading the files and trying to relink them together. Sorry
to rave on about it and not really provide an answer but I just had to argue
for XML.
"Bonj" <a...@b.com> wrote in message
news:%23B3kUnm...@TK2MSFTNGP12.phx.gbl...
Jim Carlock
all are, and if the format is defined, XML is, and if something
already exists to to import from that defined format, and if that
defined format is easy to read, XML is very easy to read
(in a sequentially viewing context), why not use the tools that
are given to you?
All the padding, is like the extra weight of a motor on a power
saw. You can still use a handsaw to do what you'd like, and
the extra weight if you're not daunted by it, is nothing to concern
yourself over. In the end, the engines will win.
I think you can compare it to trains. They came along and put
the horses and wagons out of business. They carried a lot more
baggage, they took a long time to build, they were very very big
and the power of the engine pushed away all concerns about
what it can haul.
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Bonj" <a...@b.com> wrote in message
news:eFiy%23jm9D...@TK2MSFTNGP12.phx.gbl...
Joseph M. Ferris
> #pragma warning (XML_RANT : ON)
> Wrong, it is very bad. :- XML is a poncey, unnecessarily complex, and
> probably French, "technology". Why bother define a protocol for something
How can it be wrong? Opinions are subjective. My opinion is no more
fact than yours is. <g> As far as the French goes, I'll give you a
point for that one. ;-)
> which simply pads the data you want to store? I must admit, I can see how it
> is useful. But I can also see how text files are useful, and I can't see how
> any sort of 'standard' for putting all the data in tags is going to make the
> program that writes or uses the data any better. Thus, there IS no point in
> XML files whatsoever. No offence, really - to either you or your great
> software designed for reading these files - but the only question that
> remains is (why?)
Interoperability is a start. Using XML as a transport and applying it
to a predefined messaging structure, such as SOAP, allows for the
creation of Web Services that can be accessed by anyone who can supply a
valid SOAP message. The additional technologies that relate to SOAP and
XML, such as WSDL, allow for "discovery" of a Web Service that will
allow for an application to describe itself and its interfaces to a
calling application. In turn, and with a small amount of logic, the
calling application can use the Web Service.
Like I've said before. XML is a great technology for those who actually
have a proper use for it. If you primarily develop single user desktop
apps or client server apps, XML is probably not going to buy you much.
When the time comes that you need a solution for a scalable, flexible
data transport mechanism for a distributed application, XML will start
to look more attractive. Add a (relatively) simple schema, and you can
perform a lot of data validation automatically. Add a stylesheet, and
turn your data into HTML files, PDF documents, RTF, etc.
The only problem that I have with XML is that it is applied to the wrong
situations at the wrong times. Project managers and C*Os (wildcarded on
purpose) want to see it because it is trendy. My first exposure to XML
was being "forced" into using it to store simple information, when a
simple text file would have done fine. I hated it. I thought that
there was too much code involved, and that it was overly complex.
However, when it became time to abstract a set of related sets of
information in a database to an easily transportable and human-readable
object representation, XML was the perfect medium. It is all a matter
of perspective.
And as it ties in to the OP. If you are using XML on a Windows platform
and would like to use a Win32 binary, as opposed to a Java application,
MSXML *is* the best choice because of a clearly understandable object
model, ample documentation, good examples, and decent performance.
--Joseph
Joseph M. Ferris
I can open an XML file and assign an arbitrary node's value in two
executable lines. Four if you include to object declaration for the
parser and the variable declaration.
I would be hard pressed to be able to do that with a text file -
especially in a large text file, looking for an arbitrary value based
upon the value of its descendants through its hierarchy. <g>
BTW, the original poster meant that he would not like to write the
parsing routines. I can't blame him. If there was not a parser to use,
I would agree with you, Ben. ;-)
--Joseph
AFN
and I have to do something with it from VB6. Anyone else care to help with
the original question?
"Bonj" <a...@b.com> wrote in message
news:eFiy%23jm9D...@TK2MSFTNGP12.phx.gbl...
>
AFN
mean? I looked at it, but I don't see anything about a parser group of
methods. It refers to using the DOM directly, and I'm really looking for
some abstraction through a component.
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:uQfUdIl9...@TK2MSFTNGP12.phx.gbl...
Joseph M. Ferris
> I'm not seeing what to download there. I see a 4.0 SDK. Is that what you
> mean? I looked at it, but I don't see anything about a parser group of
> methods. It refers to using the DOM directly, and I'm really looking for
> some abstraction through a component.
Yes, they renamed it since I've downloaded it. You want to follow the
link named "Microsoft XML Core Services 4.0 Service Pack 2". It
contains the MSXML objects which contains a SAX parser and a DOM parser.
It should be exactly what you are looking for.
The SAX parser sequentially reads through an XML document and raises
events that describe what it encounters. Mostly handy for read-only
operations. The DOM parser loads the entire XML into memory and allows
you to query it with XPath expressions to return data as you want it.
Good for more flexible parsing and read-write operations.
The direct link to the page (watch for the wrap) is at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=3144b72b-b4f2-46da-b4b6-c5d7485f2b42&DisplayLang=en
--Joseph
AFN
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:eIBodwy9...@TK2MSFTNGP09.phx.gbl...
Bonj
> Ooooo....French....that's a big insult there. (LOL)
What, to the French, or to XML? :-)
Bonj
> fact than yours is.
I know, I know :-) (reminds me of a mate at uni who used to like the Beatles
so much he would argue that my opinion that they made boring songs was
simply *wrong* for ages...)
>
> Interoperability is a start. Using XML as a transport and applying it
> to a predefined messaging structure, such as SOAP, allows for the
> creation of Web Services that can be accessed by anyone who can supply a
> valid SOAP message. The additional technologies that relate to SOAP and
> XML, such as WSDL, allow for "discovery" of a Web Service that will
> allow for an application to describe itself and its interfaces to a
> calling application. In turn, and with a small amount of logic, the
> calling application can use the Web Service.
you sound like a - what do they call 'em. "Cheerleader.NET" ?!
But surely you've got to specify and implement the way in which the web
service responds to requests, and thus you might aswell specify the protocol
aswell? You can keep it efficient in terms of disk space - by not having
tags, and in terms of resource - by making it generic enough just for the
services you intend it to be able to support/port to (now and in the
future)?
>
> Like I've said before. XML is a great technology for those who actually
> have a proper use for it. If you primarily develop single user desktop
> apps or client server apps, XML is probably not going to buy you much.
> When the time comes that you need a solution for a scalable, flexible
> data transport mechanism for a distributed application, XML will start
> to look more attractive. Add a (relatively) simple schema, and you can
> perform a lot of data validation automatically. Add a stylesheet, and
> turn your data into HTML files, PDF documents, RTF, etc.
>
> The only problem that I have with XML is that it is applied to the wrong
> situations at the wrong times. Project managers and C*Os (wildcarded on
> purpose) want to see it because it is trendy. My first exposure to XML
> was being "forced" into using it to store simple information, when a
> simple text file would have done fine. I hated it. I thought that
> there was too much code involved, and that it was overly complex.
yeah, don't get me wrong - fine if it definitely does make your distributed
application development easier - I just can't picture how it could though
myself that's all!
Bonj
definition of the fields in the XML files, and a set of methods that are
used for reading and updating the data. And you *need* these classes for XML
to be at all useful and efficient. Is that what you mean? It's starting to
make a *little* bit of sense, albeit not a great deal......
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:u5rtYBn9...@TK2MSFTNGP10.phx.gbl...
Bonj
an issue with the communication between two different entities (as crops up
a lot in these newsgroups) then you need to specify which of those you
control and which you don't.
"AFN" <DELETEnewsgro...@yahoo.com> wrote in message
news:Yc8Zb.9373$Le2....@twister.socal.rr.com...
Joseph M. Ferris
> you sound like a - what do they call 'em. "Cheerleader.NET" ?!
> But surely you've got to specify and implement the way in which the web
> service responds to requests, and thus you might aswell specify the protocol
> aswell? You can keep it efficient in terms of disk space - by not having
> tags, and in terms of resource - by making it generic enough just for the
> services you intend it to be able to support/port to (now and in the
> future)?
Nah... Web Services are actually useful, and I am not stuck using
Microsoft products to implement it, nor am I stuck using Microsoft
proprietary standards. ;-) As much as I hate to admit it, you are
partially correct in your observation about efficiency. <g>
The problem comes in the terms of bandwidth more than disk space,
though. As hard as it is for me to remember, there are still people out
there who actually use modems to get on the Internet. I'll give you the
scenario where we use Web Services...
The point of entry for our customers to consume our service is through
our web sites. For various reasons, the web servers are running a
flavor of Linux. Once the user performs a series of actions, a SOAP
message is generated. This message can then be sent of HTTP (or HTTPS
from outside of the firewall) to component servers that host the
business logic in the form of COM components.
What is really nice about Microsoft's implementation of SOAP (besides
being fairly compliant to the standards) is that their toolkit will map
the nodes of the XML to the parameters of the exposed functions for me.
So, for all practical purposes, I just write a standard ActiveX DLL
and the toolkit will generate the mappings for me.
Function returns are handled in the same way. They are mapped into a
return message with the same technique. The return message is sent back
to through the open TCP/IP connection for consumption by the waiting
process. It is really important that the XML contain only the
information that is required for the specific call to the Web Service,
or we start wasting bandwidth.
The backend language for the web servers (PHP) also has a library to
handle the SOAP messages (creation and consumption) that limits the
amount of parsing required for immediate use of the data.
Sounds like there is a lot more to it than there really is. But I only
explained it so that you might get a better sense of the environment
that we use. We go from Linux->Windows->Linux. Realistically, because
we are using a standards-compliant format, we also can do
Unix->Windows->Linux, Windows->Windows->Windows, and Mac->Windows->Mac.
But your question was really "Why?". The reason is that the web servers
might not always be the consumer for the service. Without making a
single code change on the backend, we can have desktop applications talk
to the Web Services and we can have outside consumers connect directly
to the Web Services in the form of using them as an exposed SDK. Since
we use a standard, all we tell them is that we require a SOAP compliant
envelope (which can be validated outside of the scope of the system via
its XML Schema) and a valid payload. The payload itself can be
validated by a Schema, as well. This additionally takes the load off of
the component servers and allows them to strictly process data and
allows validation to occur on the level of the consumer.
> yeah, don't get me wrong - fine if it definitely does make your distributed
> application development easier - I just can't picture how it could though
> myself that's all!
Understandable. I was in the same boat when I was first exposed to it.
What I described is actually a very simplified version of what we have
in regards to a distributed application. There are other niceties which
don't have anything to do with this discussion (like request load
balancing, dynamic processing, etc.).
Some other ways it makes things easier:
1. Multiple developers could be writing web services at given time.
Having a standardized transport is one less thing that they will need to
worry about. It practically becomes transparent. Using the tools that
we do (Microsoft SOAP Toolkit, primarily), allows the developer to write
a simple COM component. They don't need to think about XML at all.
2. Reusability. Not all of the Web Services contain business logic.
They can contain common reusable routines. By placing them in a Web
Service, they exist in a singular location where multiple application
can use them and be privy to updates without having to update any
software on the client machine.
If you do get the opportunity to use it, you might like it - or you
might not. At first, I found it bulk and awkward. Once I figured out
how to use the stuff, I found that it wasn't bad at all. ;-)
--Joseph
Joseph M. Ferris
> Right, so there is a *pre-built* set of classes that deal with the
> definition of the fields in the XML files, and a set of methods that are
> used for reading and updating the data. And you *need* these classes for XML
> to be at all useful and efficient. Is that what you mean? It's starting to
> make a *little* bit of sense, albeit not a great deal......
There are different parsers out there that handle the mundane tasks of
parsing and can either deliver the raw data in the form of an event
driven model (the SAX parser) or can create a queryable in-memory
resource (the DOM parser). It allows you to work with the data and not
fudge with the I/O.
Of course, you don't need them... A masochist might actually enjoy
writing an XML parser. ;-)
--Joseph