[sc34wg3] SIDP vs Assertion types

[Robert Barta]

On Sun, Apr 27, 2003 at 11:05:03AM +0200, Jan Algermissen wrote:
> > So, is it a fair statement to say that TMM is meant as a platform
> > ("bus") to integrate data repositories (relational DBs, XMLlish data,
> > other TMish data) into ONE common data framework?
> 
> In a sense...yes.
> > 
> > If so, then I would have assumed that the propagators have thoughts
> > and/or experiments on this for relational data? 
> 
> What exactly do you mean by 'relational data'?

As mentioned offline, for me different data has a different degree of
'structuredness'. "Relational data" is application data which can be
easily mapped (probably right word :-) with a ER-model.  You can also
take an XML structure holding information about weather conditions,
but the mapping is not so obvious.

> > The HTTPGET
> > application is certainly fascinating, but would not fully demonstrate
> > the strength of this approach to me. OTOH, you probably would have
> > used that already if you had.
> 
> 
> I am afraid I don't understand the last sentence, what do you mean?

Well, if I had to sell some idea to someone then I would have used one
obvious and - potentially useful - application of that idea. Providing
an HTTPGET application as demonstration what can be done is certainly
nothing compared to mapping a particular relational DB.

But, as I surmised, since we never saw this, it does not exists in a
presentable form. Which - by itself - is ok, but makes it difficult to
sell the idea.

> > Anyway, is this meant for read-only purposes?
> > 
> >   - application A uses relational DB and a TMA_A describes how to
> >     "view" the data TMish
> > 
> >   - application B models its data as TMA_B and can use data from A
> > 
> > Or is this also meant in both directions: read and write?
> 
> Certainly read and write. If I wrap a relational database with a TM
> 'frontend' there is of course the possibility to 'add an association'
> etc.

Phew! Very nice to have, but I am sceptical that that can easily fly.
It is worth a try but might sound much more like an "industry
standard" first before it becomes a "standard". I do not want to
repeat the fate of CORBA, SET, ...

> > And what about querying? If application B makes a query, is this query
> > translated into TM-speak via TMA_B and then propagates to A and is
> > executed using the inverse of TMA_A.
> 
> Huh?

>From what I understood:

       +---+                 +---+
  +--+ | A | +-------------+ | B | +--+
  |  | |   | |             | |   | |  |
  |  | +---+ |             | +---+ |  |
  |  +-------+             +-------+  |
  |                                   |
  |              TM bus               |
  +-----------------------------------+

Application A's data is described via a TMA_A, B's data (or part of
it) with TMA_B. Application A wants to query the TM-space data which
is either hosted inside the TM-bus or inside B.

In the letter case the query must be forward-translated via TMA_A (if
that is formal enough) and must be back-translated via TMA_B.

Or something like that...:-)

> > Or is my understanding too mechanical and no formalisation of TMA
> > definitions can exist? But then how can we formally test TMM
> > conformance of an application?
> 
> Well, recent postings by Lars on conformance made my realize that it
> makes no sense to 'conform to a data model'. Taken to the relational
> world, it makes no sense to claim/verify that an application is
> conformant to the entity relationship model. Who cares how Oracle et al.
> actually implement their stuff? All that counts is that their APIs
> (=SQL 'processor') conform to the SQL standard.
> 
> So, I really do think that conformance to the SAM (or TMM) makes not much
> sense at all, it is entirely a matter o API/Query languge conformance.

...and test suites, yes.

\rho