Re: Navigation question

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 27 Feb 2007 15:46:21 GMT
Message-ID: <hnYEh.1934$PV3.27824_at_ursa-nb00s0.nbnet.nb.ca>

Walt wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1172534823.070193.104950_at_k78g2000cwa.googlegroups.com...
>

>>Walt wrote:
>>
>>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message
>>>news:1172505529.681070.131640_at_q2g2000cwa.googlegroups.com...
>>>
>>>>On Feb 26, 8:28 am, "Walt" <wami..._at_verizon.net> wrote:
>>>>
>>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>>>
>>>>>news:1172444333.974143.227280_at_q2g2000cwa.googlegroups.com...
>>>>>
>>>>>
>>>>>>On Feb 23, 10:10 am, "Walt" <wami..._at_verizon.net> wrote:
>>>>>>
>>>>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>>>>><snip> My questions are regarding
>>>>>>>
>>>>>>>>layer 7, where "logical navigation" of a database might take
>>>
>>>place.
>>>
>>>>>>>>Does that work for you?  --dawn
>>>>>
>>>>>>>what do  you mean by "OSI layers?"  Are you talking about layers

>
> of
>

>>>>>>>protocols?
>>>>>
>>>>>>First, I'll grant that the OSI layers are not in my area of

>
> expertise,
>

>>>>>>so I might very well have this wrong.  I am talking specifically

>
> of
>

>>>>>>the 7 layers (of protocols) identified as the "OSI layers."
>>>>>
>>>>>Could you list the layers, and give a link to a web page that

>
> describes
>

>>>>>them?
>>>>
>>>>I just did a google and I'm not sure whether you had trouble finding a
>>>>link or if this is a test to see which link I would choose.  We can
>>>>start with http://en.wikipedia.org/wiki/OSI_model
>>>
>>>I know how to google.  I wanted to see what page you were reading from,

>
> so
>

>>>that we could read from the same page.
>>
>>Perhaps I should have been reading from a page.
>>
>>
>>>The page you pointed me to is a good starting place.  So you are talking
>>>about protocols.
>>
>>No, I'm talking about layers and not specifically about the interfaces
>>between them (protocols).  I'm talking about that which takes place
>>within the application layer, using the OSI terminology only to try to
>>get the focus within the app layer, rather than below it.  If the use
>>of the OSI layers was distracting, then simply zero in on application
>>software development, including all software (code, metadata,
>>database, DBMS specs of any kind) that run or serve as input to
>>executables running on top of an OS, for example.
>>
>>
>>>>If I had been quizzed, I would have gotten the top, the bottom, and a
>>>>few others by name, but I have never studied nor memorized these
>>>>layers.  I only referred to them in order to get the focus of the
>>>>question on the application layer.
>>>>
>>>>
>>>>>>Given
>>>>>>these 7 layers, I am not then talking about taking any one of

>
> these
>

>>>>>>layers and further subdividiing it by protocol, but simply

>
> referring
>

>>>>>>to it so that it is clear (that obviously did not work) that I'm
>>>>>>talking about the Application Layer.
>>>>>
>>>>>>> If so, it seems to me that application to
>>>>>>>database theory is limited to the areas where data is exchanged

>
> in
>

>>>some
>>>
>>>>>sort
>>>>>
>>>>>>>of formal protocol.
>>>>>
>>>>>>Surely not.
>>>
>>>I don't understand the above.  "Surely not" what?  Do you mean "Surely

>
> not
>

>>>limited to areas where data is exchanged in some sort of formal

>
> protocol"?
>

>>>If that's the case,  why did you refer to  "the OSI Layers"?
>>
>>I hope I explained that satisfactorily.  Since it is getting in the
>>way, rather than helping, ignore OSI and focus on application software
>>and the development thereof, including specification for and
>>instructions to a DBMS, for example.

>
>
>

>>> Database theory is highly relevant to conceptual
>>>
>>>>>>modeling, outside of this list of 7 layers, as well as to the
>>>>>>interface between developer and DBMS, for example.  While there

>
> are
>

>>>>>>surely some here who have an interest in data in some

>
> machine-readable
>

>>>>>>format that might not be all that useful for human eyes or

>
> application
>

>>>>>>programmers, I'm interested in Layer 7, the Application Layer.

>
> Again,
>

>>>>>>I am not bringing this in so that we can discuss protocols within

>
> that
>

>>>>>>layer, simply so that it is clear I'm not talking about "physical
>>>>>>navigation."
>>>
>>>If you are not talking about protocols,  then why are the OSI layers
>>>relevant to your discussion?
>>>
>>>I'm terribly confused by what you have written.
>>>
>>>
>>>>strictly DBMS navigation).  BTW, I didn't mention Pascal.  I included
>>>>JOG as the third.
>>>>
>>>
>>>Noted.
>>>
>>>
>>>>>Any navigation a programmer
>>>>>does entirely within the application is not relevant to the comments
>>>
>>>Cdd,
>>>
>>>>>Date, and Pascal have made regarding database data.
>>>>
>>>>Really?  I thought they were opposed to "database navigation" in
>>>>general, whether the application is navigating its way through the
>>>>data or the DBMS is, or some combination.  Hmmm.  Perhaps one
>>>>difficulty with the terms is that I consider DBMS specifications
>>>>related to any application suite to be "part of" that application
>>>>suite.
>>>>
>>
>>Did this clarify at all?  Thanks.  --dawn

>
> It clarified a little, but I'm still confused. You can in fact divide
> things into "layers" without regard to protocols, and the phrase
> "application layer" means something to me. However, your reference to the
> OSI layers suggested a common interpretation (between you and me) of the
> term "application layer", and you are using the phrase to convey something
> a little different than the OSI people intended.
>
> Let's distinguish between "database data" and "application data". Data can
> exist in a database, in "working storage" (to use an old COBOL term), and
> be exchange across the interface.
>
> Whether you navigate in working storage or not is entirely beside the point
> that Codd, Date, and JOG have made, if I understand that point at all. The
> point about user navigation interfering with both independence and
> optimization within the DBMS is about the navigation of database data.
>
> And, just in case, "database data" does *not* refer to copies of database
> data in working storage.

Declarative techniques benefit application development too. Received on Tue Feb 27 2007 - 16:46:21 CET