Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Why Are Schemas Hard?
 Paul Piatko responds: > > > Len: > > > > 1. What about Schemas is hard? > Jeff: > > > > To me, it boils down to whether they're conceptually hard > or syntactically > At the risk of sounding like a broken record about this, I > find that it is > too easy to declare local elements without really meaning to > (did you really > intend for <bar> and <baz> to be locally scoped?). One can > argue about the > various merits/demerits of local scoping, but the concept > should be made > clear to the schema author. I'd almost be happy with a > <local-element> > element. Yes, that may be good enough reason to denote local elements somehow, either through <complexType> elements or <local-element> declarations as you suggest. I only intended to point out that it adds a lot of verbosity and makes the schema tedious to write by hand and and noisy to read. Trade-off. Fair to ask if that was the proper trade-off to make, however. > <snip/> > > > If Schemas are conceptually hard, that's a different > matter. certainly the > > rules for namespaces, <all> model groups, and seemingly odd > inheritance > > restrictions certainly are difficult to master. Here, tools > may help by > > enforcing these rules through edit controls and choice > presentation, but > > that's not sufficient for understanding by the schema author. To > understand, > > he needs not only to know the spec (which is no easy task), but the > > decisions and compromises that were made in the writing of the > > Recommendation. > > Neglecting local elements for a moment, I didn't find the rules for > namespaces overly difficult. Considering the number of threads, web sites, FAQs, and articles about the subject, I think you're in the minority. Perhaps it's that the concepts are easy but the rules of scoping are not; in any case, there's a lot of electrons shooting down the wire that could be put to good use in lava lamps but for explanations of namespace usage in XML Schema. > I think this > is an area where the Part 0 tutorial could be enhanced. Or you could wait for a book on the subject :-) > I > can't say that I > totally understand model groups, substitution groups and all of the > inheritance rules. > > OTOH, I believe I can write simple schemas w/o ever using > these features. Yes, but how many of these features are you going to encounter as you interact with other data systems? That's the real problem with complex schema languages. No system is an island, and sooner or later you're going to have to understand all what you're being given, not just what you produced. Even with good tools, concepts can be hard to grasp, which is the point. > I > am a firm believer that simple tasks should be easy to do. Sometimes > complex tasks are hard to do and there is no getting around > it, so perhaps > some of the complexities of XML Schema are necessary. As > long as they don't > get in the way of the simple tasks I'd be happy. Object-orientation is another hard concept to grasp, expecially for people who have been programming procedurally for many years. On the other hand, once you get it, it is extremely empowering. Most problem domains map more intuitively to classes and objects than they do to procedures. Do the concepts of type restriction, substitution groups, namespaces, etc. in XML Schema offer similar empowerment to the developer? I think yes, but I also suspect that it could have been done 'cleaner'. Not a very constructive criticism, but others on this list have pointed out numerous examples where simpler would have been better. Take it easy, Jeff 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
