[sc34wg3] SIDP vs Assertion types
Mon, 28 Apr 2003 12:09:38 +1000
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'
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.
>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.