Re: Request for a poll: (was RE: Datatypes vs anarchy)

[Ronald Bourret <rpbourret@rpbourret.com>]

"Bullard, Claude L (Len)" wrote:
> 
> I made a comment very early based on my experience in the
> MID and some earlier SGML projects that trying
> to make XML or any other markup solution into
> an object-oriented programming language was
> a bad idea.  We get nothing we can't already
> do with the programming language, and we make
> the markup too heavy for its most useful applications.

What do you mean by "make XML into an object-oriented programming
language"? Are you referring to various attempts to add things like <if>
or do you mean something more along the lines of "XML carries the data
and XSLT carries the logic"? The first seems silly and the second looks
like a cute idea, but strikes me as far more complex than good ol' code.

> So, based on your paper, which I found to be
> excellent by the way,

Thanks!

> what would you take out
> based on modeling data objects (all XML is)
> to pass to object models?

Do you mean what in XML Schemas doesn't map well to object schemas? The
one thing that has to go is the notion of sibling order. Objects have no
notion of order among properties, so this just doesn't fit. Note that if
the order in which property values occur (that is, the array order in an
array-valued property) often isn't important in objects. That is, the
value at position 0 is no more important than the value at position 1.
If it is, the best bet is to use a multi-valued attribute in XML, whose
order space doesn't interfere with the order space of other attributes.

The other real problem is complex types v. element types. There might be
a general mapping of these to UML (I don't know UML), but they don't
play well with Java (and, I think C++). The problem is that there are
three possibilities in XML Schemas:

-- complex types (can't be instantiated or referenced in a content
model)
-- abstract element types (can't be instantiated; can be referenced)
-- concrete element types (can be instantiated and referenced)

and these map to only two possibilities in Java -- abstract or concrete
classes. The choices in XML Schemas seem to make sense for XML -- you
might get away with eliminating complex types and just having abstract
element types -- but don't make sense for objects.

Attribute groups, named model groups, and identity constraints also make
sense in schemas (attribute groups and named model groups replace
parameter entities and identity contraints solve many of the
shortcomings of ID/IDREF, although at a fairly high level of complexity)
but don't play that well in objects.

By the way, I'd like to point out that my basic opinion is that mapping 
XML schemas to object schemas is usually (although probably not always)
going in the wrong direction. If what you're interested in is objects,
then XML is just a serialization syntax, so there's no point in
attempting to bring baggage from XML into the object world. Just strip
your objects of their methods, forget about inheritance, and serialize
the remaining structures. The application on the other end will unpack
the data and get on with life.

The same is true with mapping XML Schemas to databases. In the general
case, the object-relational mapping from XML to databases leads to lots
of ugliness. If you're interested in storing XML documents (as opposed
to data) in a database, use a native XML database or an indexed BLOB of
some sort. On the other hand, if you're interested in the data, then the
primary structure is the database schema and XML is a good serialization
format.

As to why I did the mapping from XML Schemas to objects and databases,
it was largely an academic exercise, but also a way to find out that it
wasn't the best idea after all.

-- 
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com