XML serializing/deserializing versus parsing

Question

Hi all,
This is not a strictly java question but after reading many discussions and creative solutions offered by different members of this forum, i feel that the right audience for my question are the folks in this very forum. Moderator, if you feel this question makes sense in a different forum, where it might get better responses feel free to move it.
We are starting off on a new b2b web services project. Everyone in the group agreed that in order to appropriately serve the consumers in our space the best format to use is XML. We are java based and our first consumer is also java based, but we see in the future that our services will be consumed by other types of consumers as well. There seems to be a deep divide in how the xml structure should look like. There are two schools of thoughts. The first one (which is the popular one) is to have loosely typed tag names. Something like this
<header>
<map>
<entry>
<string>CUSTOMERNAME</string>
<string>Mahesh</string>
</entry>
</map>
</header>
The idea being, we could dump regular marshalling/unmarshalling/parsing techniques in favor of a serializing/deserializing tool (Like XStream). The argument here is that we don't worry about a schema/parsing etc and always deal with some sort of generic collection. The other argument is that parsing is more heavier (in terms of performance) than serializing/deserializing.
I believe that (i belong to the other less popular school of thought) any xml structure should have a real structure (strongly typed tag names). The problems i have with the proposed structure are
1. They are not self describing, i.e. no wsdl
2. They cant be parsed with a SAX parser (since there are no tag names, i dont think they can be parsed with a SAX parser, but if anyone here disagrees please correct me)
3. Since regular parsing is out of the question, you cant predict how your consumers are using it.
4. I think that the only place to use a serializing/deserializing technique is when you control both end points (producer and consumer).
What i wanted to find out from the audience here is what they think of the pros/cons of the XML structure described above. Specifically in terms of
1. Usablity
2. Scalability
3. Performance
The generic structure is also being pitched as the 'next gen' way of defining and using XML. Is that true? Maybe i am just getting old and need to catch up.
Any thoughts/comments are appreciated.

Answer 1

user13698018 wrote:
>
What? Of course you can parse that "unstructured XML" with a SAX parser, why shouldn't you be able to do that? It's still XML after all.
>
You are right, it can be parsed. What i meant to say was i wont be able to extract information from it easily. For e.g. if i have to read the customer name what tag event will i look for? If i look for the event that fires off when i encounter tag name 'string' that will only give me the tag name and not the value. I have to come up with some sort of counter mechanism to disregard the first tag event and look at the second event. Is my assumption correct?Well, parsing the "freeform" XML with SAX requires a few tricks but can result in code that does pretty much the same thing.
Since the information is exactly the same in both (except that one is a bit more verbose), I don't see any major differences in how it can be parsed.
The only (seeming) difference is that for "strictly defined" XML you'll need to pre-define which tags/properties exist. But even that can be avoided by clever use of xs:any and allowing other namespaces (i.e. allow a mydata:favoriteColor tag inside your myStrictSchema:person tag).
Once you do those, the two formats become even more equivalent: some of the advantages of having strictly-formed XML are lost (because you have to handle "unknown" tags again), while some of the disadvantages are lost as well (yeah! extensibility without modifying the core standard).
In my (partially humble) opinion, the "free form XML" approach is often used when people are too lazy to investigate the wide variety of tools available via official XML techniques.
>
3. Since regular parsing is out of the question, you cant predict how your consumers are using it.
>
What i meant here was, if my consumers find regular parsing techniques difficult to parse they will resort to short cuts to extract the information (like regex to pull information) and that will make it difficult to predict how consumers are using the xml and hence make it difficult to plan for changes in the future. Am i over thinking here?That's always a possible problem and won't be avoided by any choice in data format. They will try it with "strict XML" and they will try it with "freeform XML". If you have some kind of consulting function, then you can try to communicate the dangers of this approach, but in the end you can hardly force people to "do it the right way".
Which one would you use?I'd prefer the strictly specified one usually. But I don't know enough about the problem domain to give a qualified answer.