I'm not sure I agree with Len, if the claim is (?) that
XML explicitly models HAS-A.
For <foo><bar></bar></foo> we can say of the encoded
instance that "the element foo hierarchically contains the element
bar," but we have no authorization to believe that the
explicit structural relationship implies HAS-A. Maybe
bar HAS-A foo, maybe foo HAS-A bar, or maybe neither is
true if we understand HAS-A as representing the notion of
a property/attribute.
For <parent><child></child></parent> one could mean at the
application level that a parent has a child, or that a
child has a parent, or neither, or any of a thousand other
possible relationships that might be imagined; this structural
form "A hierarchically nested in B" licenses no interpretation
in terms of HAS-A, IS-A, IS-PART-OF, or anything else. Structurally
XML implies notions of is-adjacent-to, precedes, follows,
is-hierarchically-within [etc.] but a far as I know, these
structural relationships predicated of the serial encoding
have no authorized semantics in any domain.
Or... ?
--------------------------------------------------------------------
On Mon, 29 Apr 2002, Bullard, Claude L (Len) wrote:
> 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
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
