The Syntax is API Fallacy (was Re: Short Essay: Squeezing RDF into a Java Object Model)

[David Brownell]

David Megginson wrote:
> 
> Steven R. Newcomb writes:
> 
>  > The "syntax is API" fallacy is a well-intentioned simplifying
>  > assumption that, instead of simplifying, creates complexity and
>  > significantly reduces human productivity.
> 
> Just so.  When we're working in the database world, it should be quite
> easy to explain the place of structured markup by referring to the
> different layers ...

You know, I was thinking of commenting on this same fallacy from the
network protocol world.  The "Interchange Model" fits into part of
that ... protocols involve interactions though, and they're not just
request/response models in the way APIs often are made out to be.


> 1. Data Model - the physical organization of the information in
>    storage (such as a collection of SQL tables with primary keys,
>    etc.).
> 
> 2. Object Model - the logical organization of the information from a
>    programmer's point of view (for example, a collection of Classes
>    that are derived from and/or contain other classes).
> 
> 3. Interchange Model - the static, serial view of the information for
>    archiving or interchange with external systems (for example, an XML
>    document type).

I'd either add one, or augment the "Interchange" model to capture the
dynamic messaging patterns; I need to see system dynamics in my models!

  4. Protocol Model - the messages interchanged, and the rules for
     concurrently interchanging them over time.  

There are lots of ways to slice a system ... for example, many folk
like to couple the "data" (storage) and "object" (API) models closely
in a "single level store" model, like an object database rather than
a relational one.


> Data system designers are used to thinking about the data and (more
> recently) the object models, but are just starting to get their minds
> around the interchange model, now that the Web is enabling (or
> forcing) them to open up their systems and share more information with
> outsiders.

Network application designers go the other way around, and start from
that "open systems" world ... but have only slowly begun to back into
object models as a tool to facilitate the evolution of applications.

One of the reasons I spent a bunch of time in the CORBA world was to try
to encourage that to happen more quickly.  It didn't happen to my own
satisfaction ... and the reason is IMHO what one might call the "Protocol
is API Fallacy".  Folk focussed on the object aspects and treated those
protocol issues more as afterthoughts than primary goals; so they ended
up with a system that works better for APIs than for protocols.  (And
yes, there was lots of attention on integrating the storage and API models
automatically too -- similar effect.)


> The most important point in this structure is that the layers are
> isolated: there is an n:n relationship between interchange models and
> related object models, and an n:n relationship between object models
> and related data models.

And similarly, protocol models ... 


>  > Einstein once said something to the effect that things should be as
>  > simple as possible, and no simpler.  In the domain of information
>  > interchange, groves, inheritable information architectures, and
>  > property sets for inheritable information architectures make things
>  > as simple as possible, and no simpler.
> 
> Fair enough, but there is no single data model or object model that is
> appropriate for all systems, whether they happen to use XML or not:
> Groves (or the DOM, for that matter, or the RDF data model) can serve
> as an intermediate layer, but there needs to be a domain-specific
> object model built on top that hides and abstracts the details.

Developers looking at a large system will start to seem very much
like those blind men feeling the different parts of an elephant.

Each will need a domain-specific model (trunk, ear, tail, side, etc.)
and the model that's most effective for their particular problem
domain (data, object, interchange, protocol, etc) may not be very
useful for the other problem domains.  While the universal model
("elephant", or "application" depending on which side of the metaphor
you're working with :-) isn't suited for detailed work.


> XML should rarely be the central focus of a system's design, any more
> than SQL or CORBA should be; it's just a (very good) enabling standard
> for the interchange layer, just as SQL is an enabling standard for the
> data layer and CORBA is an enabling standard for the object layer.

Right.  The "Protocol is API Fallacy" makes the same mistake that the
"Syntax is API Fallacy" does:  assumes that one tool can and should
enable standards at more than one layer.  To the extent that it does
so, it often does so by sacrificing important functionality.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)