xml-dev - Re: The Syntax is API Fallacy

["Jonathan Borden" <jborden@mediaone.net>]

David Brownell wrote:

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

    First, let me preface this by commenting that I am a proponent of
layering, and there is much useful insight gained by layer analysis in
system design. That being said, the RPC model, now the distributed object
model defines a specific mapping between a syntax layer above the network
layer (e.g. DCE-RPC/NDR over TCP/IP) which defines a direct correlation
between the "API" generated by an IDL compiler and network PDUs. So the 7
layer OSI model can be applied to systems design.
    Where does XML fit into this equation? XML-RPC replaces NDR PDU
representation with XML PDU representation. E.g.

    1) transport = TCP/IP
    2) protocol = HTTP (POST),
    3) PDU is a MIME message of content-type: text/xml or application/xml
and whose contents are an XML document

    Via this mapping, one can *compile* IDL e.g. CORBA or DCOM into an
HTTP/XML binding. HTTP/XML replaces the IIOP or DCE-RPC. This is what is
known as XML-RPC.

    This formalism is useful for distributed object calls where the objects
maintain their own distributed identity (e.g. a URI) and communicate via
network PDUs (so the API call *does* map onto a request-response at the HTTP
procotol level).

    Another method is to send 'copies' of objects over the network. Is is
called 'marshal by value' (MBV). XMOP (see
http://jabr.ne.mediaone.net/xmop.htm) describes a method to MBV Java and COM
objects via XML.

    In general when MBV is employed, the object has a 'save' and 'load'
method that serializes the object to a stream. The contents of this stream
can just as easily be an arbitrary XML document. In this case, the XML
document IS EXACTLY the network wire level representation of the object.

    Regarding the DOM: A DOM object is a special case object whose
serialized format is an arbitrary XML document. Other objects (e.g. user
object) may choose to serialize their state into an XML stream directly, or
via code reuse, employ a parser object to assist with this serialization.
SAX and DOM objects are two types of parsers. Hence one type of object
serialization implementation may choose:

    load(DOMDocument x) and save(DOMDocument y)

as a method to implement persistence. An advantage of this approach is that
it allows the same implementation to be used for both network marshalling as
well as storage into a database which provides a DOM wrapper. If databases
arrive which support the SAX interface, this too would provide the same
benefit of code reuse to the object implementor.

    API, Syntax Protocol etc describe different layers in a system. When
well known/standard interfaces are developed to link different layers in a
system, system developers can concentrate on the important tasks of system
design and object analysis and allow the plumbing to do its job. The Grove
formalism is one mechanism of converting between serialization formats (e.g.
XML) and an object API (e.g. the DOM). IDL is another mechanism to convert
between object APIs (e.g. interfaces) and network protocols (e.g. HTTP/XML,
DCE-RPC and/or IIOP). What I am still wrestling with is where RDF sits in
this picture e.g. does it describe objects better than IDL? Does it describe
systems better than UML? (perhaps!!)Does it describe graphs better than
XML+XSL/XPointer+XLink? In the continuum between object and document, what
the heck is a 'resource' anyways?

    What I am waiting for is a mechanism to 'compile' or bind RDF into a set
of Java, COM and/or CORBA interfaces (clearly this ought be possible).

     In the distributed object world, the interface (which here is called
the 'API') is primary and the network plumbing and serialization format is a
detail to be taken care of by the system. In the document world, the
serialization is primary and the API is merely a mechanism to allow access
to the data. Clearly both views are important and ought to be equally
incorporated into the 'new world view'. I call this 'Web centric distributed
computing' for lack of a better catch phrase.

Jonathan Borden
http://jabr.ne.mediaone.net



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)