Re: Multi Valued Interface Models?
Date: 14 Feb 2006 07:41:58 -0800
Message-ID: <1139931718.457074.112250_at_g47g2000cwa.googlegroups.com>
JOG wrote:
> I'm starting to believe that Marshall is right and this is all just far
> too abstract - the terms "data model" and "representation" are just so
> semantically redundant that perhaps this discussion will just
> inevitably remain at cross-purposes. However x's MVC example has served
> to highlight this:
>
> Dawn wrote:
> > x wrote:
> >> All the data in a MVC is in the Model part of it.
> > No, it isn't. It has to cross from the Model part into that interface
> > between the software and the user called the View. That View has a
> > logical model of the data associated with it.
>
> Okay, I understand your point even if I don't like the terminology -
That makes my heart leap -- thanks!
> the View in MVC must clearly have a way of structuring its data, after
> being passed it from the MVC's model module. Traditionally this might
> be some form of OO or an ad hoc variable storage - but why on earth do
> you think that it could absolutely not be the RM sitting there in the
> internals of the View module?
I'm trying to narrow down the words to restate it a different way (working on a blog entry to post, likely tomorrow)
>
> Perhaps considering an example mathematically might illuminate matters.
> In MV:
>
> "The Person with name(x) has email(y) and email(z)"
The proposition stated in non-RM terms might be more like
The Person with name(x) has a list of emails(y,z)
> obviously holds identical information as the 1NF propositions:
>
> "The Person with name(x) has email(y)"
> "The Person with name(x) has email(z)"
In this case, think of the ordering of the e-mail addresses as important. If you are going to send this person an e-mail, start from the top and only if that bounces do you need to go to the next.
The Person with name(x) has email(y) in position(first). The Person with name(x) has email(z) in position(second).
> So whether it uses non-1NF or 1NF the "view" holds _exactly_ the same
> information (as in it is mathematically identical). Are you denying
> this dawn?
If you add in the ordering information, you can get a view of the RM version of the propositions that is logically equivalent, but not represented equivalently. In other words, you are not going to get the original proposition back out of the RM model. You will get the person's name, x, repeated, for example If we were only looking for logical equivalence, we could model the data with 0's and 1's and call it good. There is a reason we don't do that, however.
> If not, all it takes is the refresh function to make two calls to the
> view's internal storage instead of one.
The question is not whether it is possible. It is surely possible to map anything that is represented in a computer in many ways.
> This might be less efficient
> but it certainly isn't invalid or impossible, which appears to be your
> blog's standpoint.
It is certainly possible to write the required software because we can translate between the RM and other models. The UI itself cannot utilize the RM for its data model. For example, HTML has been nudged into XML (xhtml) but it is not possible for it to get nudged to SQL-92 or any other implemention of the RM that is not extended so as to no longer be the RM (even if you add the "make it pretty" and "shape into this UI widget" features). That is because the model of the UI cannot make do with the information principle (which is central to the RM as I understand it). This is especially true if you view the RM as implemented in SQL and as the majority holds as requiring 1NF. If you include RVAs, then you need only add ordering.
I realize, however, that the purpose of the RM is for use with stored data ("large shared data banks"), and it is surely possible to use the RM for the database and other models elsewhere in the software. That is what is commonly done. You cannot use it across the board, but you can use it for the database.
I feel like I'm getting closer to communicating my point, maybe? --dawn Received on Tue Feb 14 2006 - 16:41:58 CET