Another comment from , noting that I seemed to have ended up in more or less the same place, asked what I think of the XSD guidelines that Kohsuke Kawaguchi posted several years ago. I remember reading and dismissing his guidance at the time because of his assertion that you shouldn't seek to understand XSD. In my experience, if you are going to argue against the conventional wisdom with any hope of success, you need to ground your argument in a deep understanding of the topic not a claim that it would take too long to understand.
Take, for example, the argument he makes in favor of avoiding local element decls (LED) because they aren't namespace qualified, making it harder to write instances. The lack of LED namespace qualification is just a default and you can change it by marking your schema elementFormDefault="qualified". In short, his argument is easily overcome if you understand schema. There are arguments to be made against the use of local element decls: they can't be used to start a validation episode and you can define two local elements with the same qualified name but totally different semantics.
All that said, yes, I reached more or less the same conclusions and I now agree with many of Kawaguchi's conclusions, if not his arguments. In retrospect, part of me wishes I (and many others) had just taken his (and many others') arguments on faith without deep understanding, but that's not in my nature. Maybe, if enough people had, the industry wouldn't have so blindly embraced XSD. But I was caught up in the value of nominal complex types, and object mapping; it took me a long time to see that there is no future there and to realize that the best I could hope for XSD was to salvage something workable. On the upside, I've now spent enough time with XSD to know that when you balance what it offers and what it costs, and I have been able to get to a place that makes me reasonably happy.
Posted
Aug 25 2004, 07:40 AM
by
tim-ewald