oops see you main comment.
:)
BJ Freeman sent the following on 8/10/2008 2:35 AM:
> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
>
>
>
