Re: Multi Valued Interface Models?

x wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1139465598.886815.75750_at_g43g2000cwa.googlegroups.com...
>
>
> > OK, no, my argument is that it is not possible to employ the RM as the
> > data model for a general user interface.
>
> Why not ? And why are you using HTML and XML as an example ?

The User Interface could be specified with any tools in the implementation. I figured UML was generally acceptable at this point for showing a model of data using a class diagram.

> Why not using a real example of an application interface ?

I'm looking at the model of data for a user interface and then said that same model could be implemented in xml, for example, for data exchange.

> What is a general user interface ?

I recognize that one can prepare an interface to the user that shows the data the way a SQL-DBMS product shows it (some products, unforuntately, do) so there are no lists, no multi-select drop-downs, etc. Such a UI could be modeled with a relational model. But it is not the case that every UI could be modeled using the RM, as indicated in the blog. I could have said "arbitrary" instead of general.

> HTML/XML/HTTP is a poor low level complex way to describe an interface.

I thought of it as a high level way. I wasn't intending to bring HTTP into the picture, only to take an example of an arbitrary UI. Without loss of generalization...

> Are
> you trying to use a high level tool to model a low level one ? (like
> implementing assembler in Pascal or Prolog )

No.

> One does not need to model all interfaces with RM.

OK, now we are getting somewhere. In fact one cannot model all interfaces using the RM, right?

> Just the ones at the highest level.

I'm not tracking on this.

> If you want to use the same model for
> all interfaces you can always use assembler programming for that.

Yes, given a programming language as the implementation of a data model, I would agree with that. What are other options for that data model (and implementations thereof)? One model we cannot use is the RM. Languages that implement the RM cannot be used as the exclusive language for the user interface. Any disagreement with me on this one likely stems from some difference in understanding of <em>data model</em> or a common understanding of a data model for an interface. SQL is the language used to interface with an RDBMS and the model is attempts to employ is the RM. What models can be employed with the interface to the user (replace the dbms with a user and model the data).

> Have you noticed how hard is to write all the HTML&Co code by hand ?

Very painful, yes. And then I had problems with putting xml in html across browser platforms and ended up replacing < with &lt; Ugh!

> Have
> you noticed how hard is to maintain this code when you have to use reverse
> engineering for it ?

I'm not sure I understand what you mean with that.

> The RAM for the computer we use is seen as random access arrays. This is the
> lowest level. The C language allow one to see a sequence of memory cells as
> a numbers or a string and to build sequences (struct), iterations (arrays)
> and variants (union) of typed sequences of memory cells.
>
> This is not enough. Enter the marvelous world of dynamic memory allocation
> and pointers. Suddenly the memory is not a sequence anymore.
>
> How could one represent such data with XML/HTML ?
> Why is this superior to the solution proposed by the RM ?
> What has been lost with the extention of binary relations to n-ary ones ?
>
> For the normalization algorithm from "0NF" to 1NF Codd made two
> hypotheses:
> 1) the keys are not complex
> 2) the graph of the domains is not complex
>
> I would add another one: there are keys.
> I don't understand the hypothese 2) and I do understand your ripple delete
> example.

Did you mean "do" or "do not" in the last sentence?

> Personally I have found SQL to be hard to learn in comparation with the QBE
> interface from Borland Paradox desktop DBMS for DOS for example.
> I liked the "bidimensional" "query" language embeded in PAL language.
>
> SQL proved to be impossible to teach to some highschool graduate unlike the
> QBE interface from MS Access.

Yes, QBE has its charm.

> I also like Quel language but I prefer QBE (the one written in ASCII).
>
> > Surely you can use the RM to
> > persist data that makes its way to a UI, but you cannot use the RM as
> > the data model of the interface to the user.
>
> Why not ?

Dang, I still didn't explain it well. I'm going to have to find new ways to say this. The RM is the model behind-ish SQL (for our purposes we lose nothing by saying this). SQL is a language to interface with the database. We have other needs for interfaces, such as the interface with the user. SQL and its model cannot fill the bill there if you think of the software using a data model to talk to the UI like it uses a data model to talk to the database. It lacks any ability to handle the example I gave in the blog.

> > You need an understanding
> > of what a data model is (e.g. from my blog entry The Naked Model).
> > Then separate yourself from thinking about the data model for the
> > database (that is the model of the interface to the database) and focus
> > on the data model of the interface to the user. It simply is not
> > possible for the RM to be the data model for that interface.
>
> Why not ?

Again, clearly I will have to come up with a new way to say this.

> > > But it appears to me that this neglects the point
> > > that RM takes the principal that its model is interface independant -
>
> > Come up with a definition for data model as in the term "relational
> > data model." What do you mean that it is interface independent. It is
> > all about an interface.
>
> "You can paint it any color, so long as it's black "

Data models back interfaces, such as the data model used to interface between one piece of software or a human being and a SQL-DBMS. Look at the data model behind an arbitrary user interface.

> > > the data model does not know if you are going to represent the data in
> > > an "entity" format as you specify in the UML of your blog or some
> > > differing format - perhaps an interface that lists every possible
> > > colour of an animal, perhaps something else...who knows? Not the data
> > > model that's for sure.
>
> > I'm not talking about the data model of the database in this case.
> > That might be what you are referring to as "the data model." I'm
> > talking about the data model of the interface.
>
> How are those data models different ?

They don't need to be. However, if you want to use the same data model for both, you cannot use the RM. But you have read each of my blog entries and you are not tracking with me on that point, so I'll keep working on how to say it. It is not (yet) an argument against using the RM for the interface to large shared data banks, as Codd was working on. I am right now showing that it cannot be the data model behind a UI. I'm not sure which part of the argument does not resonate yet, but I will see what I can do to make it clearer. Thanks. --dawn Received on Thu Feb 09 2006 - 16:44:02 CET