From: Manos Batsis [mailto:]
> From: Bullard, Claude L (Len) [mailto:]
> XML is good for HAS-A; not too good for IS-A.
>>Why not? Because a child node defaults in "has-a" in human eyes?
No, because the structural relationship is explicit, not interpreted.
Is-a requires information that is not there by default. IS-A must
be inferred from the GIs or other names. One can create XML applications
to state this explicitly, but it is done in the namespace, not the
structural scoping.
Berners-Lee makes a good case for RDF but it comes down to the
same case for any application language: it has application
specific semantics. We have this argument over and over
and over again in every design exercise where the designer
presumes wrongly what XML objects are good for out of the box.
> XML is good for data objects; not so good (in fact, rotten)
> for object-oriented objects.
>>A certain design may have rotten parts but one cannot argue against the
>>usefulness of it.
Any application language has use based on the application language
design. XML is rotten for it because XML, itself, is just a set
of data objects. What one does after that is one's own business
or application. The problem with Berners-Lee's article is in not
being clear that XML is a metalanguage, and that any metalanguage
will be more expensive in the beginning with regards to declaring
application semantics. RDF is an application language. It
is terse for what it is used for and it is demonstrably useful.
The furor over RDF may have more to do with not wanting to have
inference engines in all system designs, but that's just a guess.
In fact these aren't required, but where they aren't, one has to make
the case for RDF.
That is itself, an interesting topic: what are
the de jure semantics of RDF processors? Why would
I need one? (Arguments about ubiquity are just political
arguments for hegemony: skip those. They don't sell
here. Arguments for functionality, particularly, free
functionality get a hearing most anywhere.)
>>I see OO influenced XML structures gaining ground
>>every day from RDFS to SOAP to JSML[1] and for good reasons. They
>>provide for cool stuff from MVP to plain multilanguage serialization and
>>they escape the useless hype of implementations that suffer from the
>>"relational normalization rules" you mention below (i.e. my favorite
>>vendor's database module that outputs or "supports" XML)
You see applications of XML that apply to object-oriented processors.
That's fine. That is how it is supposed to work. Relational normalization
is a practice that increases efficiencies in certain areas of the design
(eg, maintenance, integrity) but can decrease other efficiencies (raw performance
by having to perform multiple joins).
Object-orientation done imprecisely has similar problems. Hype
to the side, a badly thought through abstract class system is as bad as
an over or undernormalized table a year after it is fielded.
> XML is pretty good for tables, but not so good
> for enforcing relational normalization rules.
>>Of course. Enforcing relational normalization rules shuts down most good
>>reasons to use XML in the first place, with the possible exception of
>>exchanging DB data between servers via http.
Whether is does or not, it takes sustained effort to enforce
it at all in XML. In relational design, it is SOP.
len
