[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: An inquiry into the nature of XML and how it orients our p
> > Hi Folks, > > I oftentimes hear of people creating XML in an Object Oriented (OO) form, > i.e., as classes and subclasses, or of people creating XML in a relational > database form, i.e., as tables with rows and columns. The use of classes and subclasses is characteristic but not definitive of an object-oriented system. An object-oriented system is merely one where all the characteristics of a thing (typically methods and fields) are bundled, and where most or all things are objects. Object-oriented systems almost always have classes, ever since the days of Simula, to be sure. But it is possible to have an object-oriented design in a non-class-based language such as C, sticking to a design pattern where each struct has function pointers for accessing the data. (And a class-based language is not necessarily an inheritance-based one either: it could use prototyping, where the class object is copied.) The other angle is that modern inheritance- oriented systems have moved away from simple classes with simple inheritance to partial classes with multiple inheritance and mixins: Java's interfaces and Scala's traits for example. So I don't know that people actually are "creating XML in an OO form", speaking strictly. I don't know that this changes any details of Roger's question, but it does change the kinds of connections we might make. Considering objects-oriented to refer to a methodology of bundling, I would say that XML is completely non-object-oriented in relation to bundling methods with data, and quite object-oriented in relation to bundling related data together. I wonder if such > forms are appropriate for XML? Does OO serve the same purpose as XML? Do > relational tables serve the same purpose as XML? I think there are a few different cases: perhaps one big distinction might be whether you are wanting to expose the Java (for example) class system, or hide it. I really like the SwiXML XML language. It is a little facade above Java Swing, where the Java Swing objects are created and connected by interpreting the XML element names using reflection. So it is a very thin layer. It is useful because many of the methods in a Swing objects are visual characteristics that get set on initialization (and perhaps not afterwards): so it is trivial to call a setter based on an attribute name. In other words, most of the methods are setters which return void, rather than functions which return some value. So this kind of complex structure, which is instantiated all at the same time, and whose interaction is largely either by setters properties (rather than getters) then by listeners, seems very amenable to an XML facade on top of the pre-existing API. But there is no requirement to model the Java inheritance using XML, and certainly not with XSD types. In fact, using the facade frees you from that complexity. Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|