[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema concepts
Stefan Haustein wote, responding to my post that responded to Jeff Lowery's: > THOMAS PASSIN wrote: > > > (...) > > > > Using OOP to build an application does not automatically require that every > > piece of the schema be an OOP object. That might or might not be a useful > > approach. An XML document may be used in a large number of ways, requiring > > different methods. So I don't think that the WD is headed in the wrong > > direction here. > > While I agree to your statement, I do not understand the conclusion: > Wouldn't a simplified XML Schena spec help all processors, regardless > if they are OOP or not? > Yes, I think simplicity is ***very*** important. As simple as possible. The hard part comes with the addendum: "but as complete as necessary". Efforts to be complete tend to sacrifice simplicity, don't they? In part, I imagine, XML-Schema is complex beause the authors are trying to be complete about difficult abstractions. So there are really two issues, aren't there? 1) Is the correct set of abstractions present? and 2) if they are, are they expressed with as much simplicity as possible? The fact that there have been so many weighty questions on the list is a clear tipoff that more work needs to be done on the WD. In other words, if your readers don't understand you, it's better to revise and rewrite than to keep on explaining what you "really mean". Are we dealing with alternative 1) or 2)? I suspect it's both, and I think different posts focus on one or the other. > Or do you see a concrete advantage of the type/element distinction > in your application field? > I have to confess that I am not completely settled in my own mind about whether there should be a distinction between "element" and "type". The main issue being, what is a "type" anyway? An element we can probably agree is more or less "That thing with start and end tags - oh yes, it can contain other elements too." But "type"??? You can have "types" without any OOP approach. In some languages, two things are can be type compatible if they take up the same number of bytes, and not otherwise. Some people consider an SQL table definition to define a type. And then there is the question of the distinction between "class" and "type". This is very important to some people, and unimportant to others. Even if we stuck with an OOP paradigm, there is not universal agreement on what either a class or type is. For example, forget methods, OK, but don't we have to leave in inheritance? But how about multiple inheritance or inheritance with restriction (i.e., the child omits some properties of the parent)? When I reflect on the above, it seems to me better to keep an element as separate from a "type" - it ought to make it easier to use without having to invoke a lot of machinery and definitions, if that's what one wants to do. And also, it behooves the standard writers to be very clear about what a "type" is and how to use it. Now, to make a "type" conveniently useable to C,C++,Java,Smalltalk,Python, and Lisp/Scheme users - just for starters - is probably going to take some doing. It's probably better to try to make our "type" adaptable - nothing that would prevent such use, in other words- by these common application environments , than is is to cause a "type" to exactly agree with the notion of "type" in any one of them. Regards, Tom Passin *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html ***************************************************************************
|
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
|