Lightweight XML DOM VB6 Class?

[dilettante]

Does anybody know of a simple XML DOM class written in VB6?

I just need something lightweight to use for communication between processing tiers written in VB6. I'd prefer the source to a class module for internal use within my own EXEs rather than a COM DLL.

I'm looking for something that can parse an input stream into a DOM object and serialize a DOM object back into a stream. I also want to have a fairly clean object model that lets me build up a DOM (document) internally from code and work with it there as well.

The markup ("XML") itself doesn't have to be wonderful or standard enough for interoperation but it needs to be text-based. Both ends of a conversation will be using the same class via a stream (TCP, etc.) so XML per se is not a requirement. The data will be hierarchical rather than flat like a typical Recordset or CSV file.

It'd be useful if it mapped markup content into various common VB scalar types as well, i.e. String, Integer, Long, Date, Boolean, Single, Double. The idea being that values stored in the DOM would be stored as native types (even as typed Variants) rather than just strings that I'd need to keep converting and reconverting.

What I'm looking for in a DOM is a linked tree of nodes where each node has a collection of named, typed attributes and a collection of named children nodes (unless the node is a leaf of course). A back-link to a node's parent node would be handy as well.


Anyone seen anything like this? I searched and came up empty except for a few "how to roll your own" articles, so for now I'm headed down that path.

 

[dilettante]

Nevermind, I've got it done.

Well, "done" is relative. I need to add support for a byte array binary type yet (probably just a hex or base64 type, I don't need CDATA sections). Then of course the documentation needs to be done yet. Bleh!

Maybe some optimization too. Way too much string concat activity going on, so I'll have to use a "fast strings" mechanism - at least for the .Serialize() method.

 

[chiph]

Uhh, classes are COM objects. But I see your point about installing MSXML 4.0

Make sure you handle the XML entities correctly - ampersand, single-quote, double-quote, less-than, and greater-than.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[dilettante]

Yep, I was just hoping to avoid external COM DLLs and use internal (private) classes. One less thing to register on every client machine, but otherwise there is probably no point.

I wanted something with a simple object model that didn't add a lot of junk to the serialized stream.

Thanks for the reminder about ' though, I'd left that one out because I wasn't going to give the ' any special significance outside of string values (only " used around attribute values). Always worth including though while I am adding it.

 

[strongm]

Whats the target OS? Given that 2000/XP/2003 all include at least MSXML 2.5 so you wouldn't actually have to redistribute anything (although you'd probably have to late bind) ...

 

[dilettante]

You hit the nail on the head. This needs to work on clients that may be any Win32 OS from Win95 on up.

Luckily I don't need to support anything standard nor do I need to validate against schemas. All I needed was a good way to work with structured data and pass it over somewhat generic communication paths (TCP streams, Telnet connections, SMTP email body text, etc.).

I also have control over the software at both ends, giving me a lot of freedom as long as I can squeeze the data through as 7-bit ASCII text. This allows me the ability to use alternatives in encoding image data and other binary iformation as well of course. Rather than base64 for example, I can use base64-B. This is encoded like base64 but uses an alphabet running from ASCII "0" through ASCII "o" and using "~" as the pad symbol. Base64-B avoids the scrambled alphabet of base64, making it easier to write code for and a tiny bit faster to encode/decode. I've looked at base96 as well, which is more compact but clusier to code because each symbol represents 6 1/2 bits of the original data.

The point is though, when interoperation isn't a requirement you can do almost any crazy thing. I'm just avoiding getting too crazy by using fairly standard XML. Always have to think of the next programmer - or myself 6 months down the road.

I inherited a bunch of stuff that uses a proprietary "tag and length" system. It was pretty nutty, a stream made up of 7-bit ASCII "fields" such as:

[tt][head][id][type][length][break][text][tail][/tt]

Where:
[tt]
[head] is an ASCII "["
[id] is a one to four ASCII digit "field ID" with the
9000-9999 range reserved as "record IDs"
[type] is a one ASCII letter "field data type" attribute
with predefined letter/type pairs, or else ">"
meaning "descend hierarchy" or "<" meaning
"ascend hierarchy"
[length] is 1 to 10 ASCII digits, a decimal "length" of
the following [text] and omitted for [type] of
">" and "<"
[break] is an ASCII "|" and omitted for [type] of ">"
and "<"
[text] is the field contents, any "printable ASCII"
string of characters
[tail] optional ASCII "]" and Cr/Lf pair.
[/tt]
Binary types are passed as strings of hex digits.

The stuff looks like:
[tt]
[9170>]
[2I3|362]
[3S24|Random/Smith Novelty Co.]
[4S19|1234 Enterprise Dr.]
[6S7|Wyoming]
[7S8|Nebraska]
[8S10|68410-2206]
[12>]
[13>]
[15S5|Smith]
[16S4|John]
[13<]
[13>]
[15S6|Random]
[17S4|Paul]
[13<]
[12<]
[9170<][/tt]

Old stuff, inherited from the '80s, probably predating SGML let alone XML. I didn't want to perpetuate this sort of thing. It looks more compact than XML, yet rather opaque as well. It also doesn't allow for any item attributes besides a "name" (ID), a "type," and a "length.