Re: Ada-Python demo

[Maciej Sobczak <see.my.homepage@gmail.com>]

> > http://www.inspirel.com/articles/YAMI4_vs_ZeroMQ.html

> However, reading the article, it looks as if YAM14 uses its own data model language

Not exactly. YAMI4 *poposes* the data model out of the box, as this is what is normally needed.
If you have a communication solution that does not offer any data model at all (ZeroMQ comes to mind, similarly to other low-level libraries), then users are forced to solve the problem of data model and serialization *in addition* to the communication, which leads to using *two* different libraries (like ZeroMQ with JSON, or sockets with protobuf, etc.) for handling what is essentially a single problem: make two programs talk. Why the hell would you want to use two separate libraries to solve this single problem?

YAMI4 recognizes that and proposes a data model that is more or less equivalent in terms of expressiveness to JSON (that is, there is a small set of basic data types, arrays and nesting). And it happens to directly map to Python's directory, which makes it trivial to use in that language and programmers in other languages have the option to describe their object in YDL. Thanks to this users can just take a single library and solve their *single* problem of making two programs talk - no need to mess with two separate products (think: licensing, integration, support, etc.).

However, YAMI4 does not force users to commit to that particular data model and if in a given system it makes sense to use other data models or serialization schemes, it is perfectly possible - YAMI4 supports also raw binary data buffers. That is, you can use anything you like (JSON, ASN.1, XML, ontologies, whatever) with YAMI4.

Interestingly, as far as I know, *nobody* does it. In other words, nobody chooses to benefit from the freedom to use anything they like. Which kind of suggests that having a data model that works out of the box is perhaps a better idea than not having it and pretending that communication and data model are independent. Technically they are, but from the usability point of view they are closely related.

> that isn't translatable into any ontology language - which seems a major problem.

Not at all. :-)

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com