Re: [xml-dev] An inquiry into the nature of XML and how it orients our p

[rjelliffe@allette.com.au]

>
> 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