Re: The Foundation of OO (XDb)

> > > > > Why not assume user-defined type support? I assume it.
> > > >
> > > > Do you mean "media format types"? I did not define
> > > > nor limit who can change what. That is an orthogonal
> > > > issue IMO.
> > >
> > > No, I mean user-defined type support such that Video is a data type.
> >
> > "Type" often implies operations, like "play", "rewind", etc.
>
> These operations are application behaviours and not data behaviours. They
> navigate among the images within a Video to choose the next image to
> display. The DBMS delivers data (ie. the requested Video value or Image) and
> does not display.

Do you mean "stream management"? I assumed that the DB would only store the file/BLOB and pass it to something else to manage the buffering, etc, of data transfer.

>
> > > > > Why should we force users to deal with filenames?
> > > >
> > > > This is the developer's perspective, not the users.
> > > > I did not define nor limit user interfaces here.
> > > > That is an orthogonal issue.
> > >
> > > What developer is involved when a user queries a database from Excel?
> >
> >
> > What an Excel user has access to is not the issue here.
> > I did not describe nor limit access controls.
>
> I did. I asked the reader to imagine how a user might interact with such a
> relation in Excel or on WebTV.
>

Perhaps I missed some messages from you.

>
> > > I can see that. Video has multiple possible representations. Why force
> > > anyone to choose? Why not support all the possible representations as
> one
> > > logical type?
> >
> > Because fat types don't belong in databases IMO.
>
> Fat in what sense? In adequately supporting all possible representations of
> a type? I think that does belong in a dbms.

What is the "type" you have in mind? Presentation type? (movie, music, still images, mixed....), Format type? (Mpeg, MP3....), content classification
(drama, comedy....)?

> > Fat types also tend to run into orthogonal divisions,
> > granularity, and mutually-exclusiveness limitations
> > in the long run IME.
>
> I suggest you address the actual example given and not some example you
> imagine.

I only saw a food example. I will try to take another look.

>
>
> > For example, a player A may be able to play MPEG
> > versions C, D, and E. But player B may only be
> > able to play D and F. Thus, is the "type"
> > divided by player or the version letters?
> > Is each sub-version a different "type"?
>
> No, they are simply representations of the same type. I thought that was
> very clear in my original example. Can you suggest ways I might have
> communicated it differently so that you would have understood?
>

You appearently said something somewhere that I missed.

>
> > What about different implementations of
> > MPEG players? Vendor M's version system
> > may be completely different than vender N's
> > version numbering system.
>
> If the different Vendors players cannot, in general, play MPEG, then they
> are not MPEG players. If they can play MPEG, they should have no difficulty.
>

Perhaps current MPEG is simply enough to not worry much about that kind of thing. However, I don't know if we can say the same about other formats, and/or future MPEG formats. Things can splinter in funny ways. There are more things to go wrong in the digital world WRT representation formats (more logical problems but less physical problems).

>
> > Does that mean we are back to dividing by
> > vendor drivers again?
>
> MPEG is a standard representation. If your vendor's player does not play
> MPEG as claimed, take the player back to the store.

Not if it is only one disk that does not work. It is ofen less effort to buy a new disk or forget about it.

-T- Received on Wed Jun 19 2002 - 02:20:18 CEST