Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Mike Well, yes, I got out in the "rest of the world", (for normal info, I worked with Software AG as a Tamino product manager before coming to the Danish Post, where I work as Enterprise IT Systems Architect), where we're solving problems, not fighting for Native XML vs. RDBMS stoerd XML. (I know of companies using Oracle and IBM MQ Series to handle all their XML with no problems and quite good performance....) In this "Why validate XML scenario", I guess that what I intended to write was: * XML Schema (DTD) can be used to validate structural constraints on the XML Documents. * Semantic validation of XML documents must be done in the application (that is until i.e. RDF-S, DAML+OIL as well as easy to use inference engines become widely available and easy to use;-)) You write: >If so, is that because the DB triggers/rules/etc. have too much of a performance burden? This depends heavily on the RDBMS and the way it is designed. For e.g Oracle I can say that I've never experienced any performance problems with the systems I've worked with. So it is not a performance issue, it is a "Semantic Issue". There are not any systems (that I know of) yet, than can validate the Semantics of your data, only the structure. But this is great, validating the structure, and having some easy top use tools for this (your RDBMS or a validating parser), is a must before you can validate the Semantics of the documents. And again, at the time being, I do not know of any easy to use and configure systems/tools, (besides building it into the application logic) that offers validation of the Semantics of a document. I hope that this helps to clarify the issue I raised, by changing the question of "When to Validate XML" over to "Why Validate XML, and what do we want to achieve by doing so". Best regards Jens Jakob Andersen
|
