they come from the xAL:2.0 standardard
Jacques Le Roux sent the following on 8/10/2008 2:16 AM:
> I had a look and put some (limited fro now) comments in repective wiki
> pages
>
> Jacques
>
> From: "Jacques Le Roux" <[EMAIL PROTECTED]>
>> OK, thanks for the link, I will study...
>>
>> Jacques
>>
>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>> I have not written much on the wiki yet because is very complicated.
>>> however part of the proposal is the stages and sequence to get this done
>>> so people that have data already in use will not suffer.
>>> in the light
>>> yes there will be a series of patches probably under different task in
>>> the same jira.
>>> http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
>>>
>>>
>>> Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>> Yes it save a lot of programming. mostly in matching the stored
>>>>> address
>>>>> with the with the user input.
>>>>> that is part of the change plan to to implement that.
>>>>> the stored postal address, would be already postoffice formatted
>>>>> for the
>>>>> country. so the matching algorithm for the user input and the
>>>>> screen to
>>>>> do this is more complicated, but will worth the effort making sure
>>>>> there
>>>>> is a usable address in the system.
>>>>
>>>> This is interesting. I think we will look forward for a Jira with
>>>> patch(es). I write patch(es) because if it's a large piece of code
>>>> it is
>>>> worth to split it in patches.
>>>> For instance at least data model and code separated. Maybe more
>>>> separation between code from functionnalities, etc.
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>>>>> I agree that addresses should not be specific to a party and could be
>>>>>> shared. Let see what other think. There may be a good reason it's
>>>>>> build
>>>>>> like that... It introduces some redundancy but maybe save programming
>>>>>> efforts...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>>>> ah, well I am working a plan to remove toname and attnname.
>>>>>>> if you read the data books it was not laid out that way.
>>>>>>> my concept was
>>>>>>> contactMechtoPostalAddressAssoce
>>>>>>> postal addresss -------------->postaladdressid
>>>>>>> ContactMechID <------------contact
>>>>>>> Mech
>>>>>>> the toname and attentent name would become part of the contact mech
>>>>>>> types with those types using the same relationship.
>>>>>>> so one postal address is in the database.
>>>>>>> Just like in the real world that is just one address, or location.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>>>>> To answer you question you have only to have a look at the
>>>>>>>> PostalAddress
>>>>>>>> definition
>>>>>>>> There are specific fields there like toName and attnName which
>>>>>>>> can't
>>>>>>>> shared. A PostalAddress is only an administrative mean to
>>>>>>>> contact, not
>>>>>>>> to locate
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>>>>>> so when someone else puts in the same address will they point
>>>>>>>>> to the
>>>>>>>>> same address or will a new record be added?
>>>>>>>>>
>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>>>>
>>>>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>>>>> <[EMAIL PROTECTED]>
>>>>>>>>>> To: <dev@ofbiz.apache.org>
>>>>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>>>>>>>>> contact mech may not always be the same address and geopoint
>>>>>>>>>>>> for an address it will always have the same geopoint
>>>>>>>>>>>> 1) how do you connect an address that already exists with a New
>>>>>>>>>>>> ConactMech.
>>>>>>>>>>>> 2) how do you connect the assoicated Geopoint that goes with
>>>>>>>>>>>> that
>>>>>>>>>>>> address.
>>>>>>>>>>>
>>>>>>>>>>> My last proposition should cover your previous demand. If you
>>>>>>>>>>> expire
>>>>>>>>>>> an address then the geo-point this address used (point to) would
>>>>>>>>>>> still
>>>>>>>>>>> exist but as the address is obsolete we don't have to care (this
>>>>>>>>>>> address and its associations should not be used anymore)
>>>>>>>>>>> Let see your new questions now:
>>>>>>>>>>> 1) Not sure to understand this one since an address is a type of
>>>>>>>>>>> ContachMech. Did you not used a word for another ?
>>>>>>>>>>> 2) PostalAddress.ContactMechId -> ContacMech ->
>>>>>>>>>>> ContacMech.TerrestialPositionId -> TerrestialPosition
>>>>>>>>>>
>>>>>>>>>> Sorry should have been PostalAddress.contactMechId ->
>>>>>>>>>> ContacMech ->
>>>>>>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>>>>>>>>>>>>> Yes , this is a good point to note. Actually the geo point
>>>>>>>>>>>>> continues to
>>>>>>>>>>>>> exist (it may be used by another thing) but the relation
>>>>>>>>>>>>> between
>>>>>>>>>>>>> it and
>>>>>>>>>>>>> the address does not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>>>>>>>>>>> but some means would need to link the terrestrial position to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> address so if the address part is disabled, through the
>>>>>>>>>>>>>> enddate, in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> contact mech, so is the position associated with it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree on the rest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>>>>>>>>>>>>> Jacques Le Roux wrote:
>>>>>>>>>>>>>>>> Yes actually, I was just thinking about the
>>>>>>>>>>>>>>>> EntityNameContactMech
>>>>>>>>>>>>>>>> pattern, not a rule indeed.
>>>>>>>>>>>>>>>> And because I wondered why we'd use this pattern in most
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len
>>>>>>>>>>>>>>>> Silverston
>>>>>>>>>>>>>>>> suggests to deal with contact informations.
>>>>>>>>>>>>>>>> At this stage I must admit that things were not much more
>>>>>>>>>>>>>>>> clear. As
>>>>>>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more
>>>>>>>>>>>>>>>> usages as
>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>> done in OFBiz.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now, please let me think loud. What is the difference
>>>>>>>>>>>>>>>> between a
>>>>>>>>>>>>>>>> postal
>>>>>>>>>>>>>>>> address and a GPS point ? Is there more differences between
>>>>>>>>>>>>>>>> them than between, say a telecom number and a postal
>>>>>>>>>>>>>>>> address ?
>>>>>>>>>>>>>>>> Obviously telecom numbers and a postal addresses have
>>>>>>>>>>>>>>>> something in
>>>>>>>>>>>>>>>> common that a GPS point does not share: they are
>>>>>>>>>>>>>>>> mechanismes to
>>>>>>>>>>>>>>>> contact somebody (or something at large). A GPS point is
>>>>>>>>>>>>>>>> only a
>>>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>>> to locate somebody (or something at large), you can't
>>>>>>>>>>>>>>>> contact a
>>>>>>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS
>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as
>>>>>>>>>>>>>>>> Len
>>>>>>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to
>>>>>>>>>>>>>>>> contact. So
>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>>>>>>>>>> rather than having it point to other things. I still wonder
>>>>>>>>>>>>>>>> though if
>>>>>>>>>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>>>>>>>>>> terrestrialPositionId in ContactMech does not make
>>>>>>>>>>>>>>>> sense, as
>>>>>>>>>>>>>>>> it's not
>>>>>>>>>>>>>>>> a mean to contact but locate. Should we not introduce
>>>>>>>>>>>>>>>> something else. Like a LocateMech, which could be maybe
>>>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> stuff in future ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I like the idea of making terrestrial position another
>>>>>>>>>>>>>>> contact
>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>> type.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I disagree that you can't contact a GPS point. You can if
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> a GPS
>>>>>>>>>>>>>>> device and a means of transportation - the same as a postal
>>>>>>>>>>>>>>> address. How
>>>>>>>>>>>>>>> is locating someone via car plus GPS device any different
>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>> locating
>>>>>>>>>>>>>>> someone via car plus a map?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can think of other uses for a terrestrial position contact
>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>> type -
>>>>>>>>>>>>>>> locating facilities or fixed assets like electrical
>>>>>>>>>>>>>>> transmission
>>>>>>>>>>>>>>> towers,
>>>>>>>>>>>>>>> cell towers, etc. They aren't going to have a postal
>>>>>>>>>>>>>>> address or
>>>>>>>>>>>>>>> phone
>>>>>>>>>>>>>>> number. If terrestrial position was another contact mech
>>>>>>>>>>>>>>> type,
>>>>>>>>>>>>>>> then we
>>>>>>>>>>>>>>> could use existing services, etc to associate that
>>>>>>>>>>>>>>> location to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> facility.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
