[
Lists Home |
Date Index |
Thread Index
]
i'd like to add more to one of my favourite perma threads, but can i
start by just modifying your example nathan? as i think it makes part of
the issue clearer.
definition: an association is a meta structure that describes how two
data sets relate.
in the example
<Vineyard>
<Lots>
<Lot id="lot1">
-- info about the lot --
</Lot>
...
</Lots>
<Pickers>
<Picker id="John">
-- info about the picker --
</Picker>
...
</Pickers>
<Assignments>
<Assignment type="isBeingPickedBy">
<participation type="Picker" idref="John"/>
<participation type="Lot" idref="lot1"/>
</Assignment>
...
</Assignments>
</Vineyard>
needs a bit more work, but it's starting to be a structure that can be
inverted and easily answer lots of questions like who's picking in lot
1? what is john doing? etc
now the couplings are explicit and can be easily manipulated.
could be done just as well with rdf (in this structure) but a bit harder
to read :)
rick
Nathan Young wrote:
> Hi.
>
> I'll be reading the links Len sent out for a while now. Up to now my
> practicing (and by practicing I mean semi-literate but personally
> useful) definition for coupling was this:
>
> Coupling is an interaction between components or applications.
>
> How tightly coupled components are is determined by the extent to
> which internal changes in one component require internal changes in
> the other. By this definition, tight coupling tends to increase
> maintenance costs. In my mind loose coupling is irrevocably
> associated with having good and consistently used APIs.
>
> In your example, neither pattern substantially changes coupling.
> Both have different kinds of fragility.
>
> Furthermore, a transform can move you from one form to another with
> no loss of data. In systems where you're using the same data lots
> of different ways, you end up with lots of end formats and automated
> ways to reach those points (many website are that now).
>
> The questions become "what formats allow you to capture the most
> information" and "how do you transform and merge data held in those
> formats". In this context, calling something a "best practice"
> carries little information. Calling something "a practice that
> optimizes for X" is closer to being useful.
>
> I associate your first use of references:
>
> <Lot id="1">
> -- info about the lot --
> </Lot>
> <Picker id="John" isOnLot="1">
> -- info about the picker --
> </Picker>
>
> With relational design, where one-to-many associations are modelled
> as attributes on the many side. Familiarity to people well versed
> in relational design is the strongest pro I can think of for it.
>
> I associate your second use of references:
>
> <Lot id="1">
> -- info about the lot --
> </Lot>
> <Picker id="John">
> -- info about the picker --
> </Picker>
> <Assignment picker="John" lot="1"/>
>
> With topic maps and modelling associations with roles. Why not have:
>
> <association type="isBeingPickedBy">
> <participation type="picker" participant="John"/>
> <participation type="lotBeingPicked" participant="1"/>
> ...
> </association>
>
> At the ellipses you can add all kind of meta data about the
> association. Time started, time ended, picking rate, etc.
>
> ----------->Nathan
>
>
>
>
>
>
> On Tue, 1 Feb 2005 07:35:09 -0500, Roger L. Costello
> <costello@mitre.org> wrote:
>
>> Hi Folks,
>>
>> Again, many thanks for the excellent comments. I am working hard to
>> assimilate all your comments, and will create a summary of all the
>> discussion soon.
>>
>> One question that several people asked was, "What do you mean by
>> coupling?"
>> Below I have made an attempt at defining coupling. Do you agree with my
>> definition? Is it complete, i.e., are there other factors that
>> should be
>> incorporated into a definition of coupling?
>>
>> Note that I have changed version #2 to this:
>>
>> <Lot id="1">
>> -- info about the lot --
>> </Lot>
>> <Picker id="John">
>> -- info about the picker --
>> </Picker>
>> <Assignment picker="John" lot="1"/>
>>
>> The Lot component just contains information about the Lot. And the
>> Picker
>> component just contains information about the Picker. The Assignment
>> element connects the Lot and Picker. ["Assignment" is not really the
>> correct name. Can someone think of a better name?]
>>
>> Okay, now for my definition of coupling:
>>
>> What is Coupling?
>>
>> Definition: There exists a coupling between two components if there
>> exists a
>> "dependency" between the components. The greater the dependency, the
>> greater the coupling.
>>
>> An obvious dependency is physical dependency. In version #1 the Lot
>> and the
>> Picker are physically dependent (coupled) on each other:
>>
>> <Lot id="1">
>> <Picker id="John">
>> .
>> </Picker>
>> </Lot>
>>
>> The Picker is a child of Lot. The Lot is the parent of Picker. There
>> exists a definite physical co-dependency between the Picker and Lot
>> components.
>>
>> A more nebulous dependency is semantic dependency. In version #1
>> not only
>> does there exist a physical dependency, but there also exists a semantic
>> dependency. Namely, the Picker is located on the Lot.
>>
>> Now consider version #2:
>>
>> <Lot id="1">
>> .
>> </Lot>
>> <Picker id="John">
>> .
>> </Picker>
>> <Assignment picker="John" lot="1"/>
>>
>> The Lot and Picker components are physically completely separate.
>> There is
>> no physical dependency. The Assignment element creates a semantic
>> dependency between the Lot and Picker, by identifying that the Picker
>> is on
>> the Lot.
>>
>> So, in version #1 there exists both a physical and semantic dependency
>> between the Picker and the Lot. In version #2 there exists only a
>> semantic
>> dependency. Thus, there is a stronger coupling between the Picker
>> and Lot
>> components in version #1. We say that there exists a tight coupling
>> between
>> the components in version #1. There exists a loose coupling between the
>> components in version #2.
>>
>> Comments? /Roger
>>
>>
>>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
