PostalAddress enhancement

[BJ Freeman]

I am enhancing the PostalAddress.
there are two parts
1)postal address specified by country.
This can be used to generate a screen to that country and do the layout
for a mailing peice.
it also specifies how to store the address information.

2)storing the address informaion.
this is a free form system that lets the complete address be stored in
the components that make up an address.

the basic part is the Addressline
it has then name of the address line that is freefrom, this would be
used to show on the UI and or the mailing piece.
there is a  linenumber and lineposition. The line position lets complex
addresses be define as separate components.
Like the BR address line
Postal Area--Postal District--Postal Sector--delivery Point
with is you can also specify the separator and where to to put it.

there are services that read the country formation information on a
Create and put in a map for a UI.
Service that Stores the data, win the free form format.

These would override most of the data currently stored in the
PostalAddress entity.

any input?

[cjhowe]

Could you provide a bit more background.  My first instinct on this is
to continue the storage as is (address1, address2) in freeform and to
have services that read/transform that freeform into local conventions
rather than storing them in local conventions.      

--- BJ Freeman <[hidden email]> wrote:

> I am enhancing the PostalAddress.
> there are two parts
> 1)postal address specified by country.
> This can be used to generate a screen to that country and do the
> layout
> for a mailing peice.
> it also specifies how to store the address information.
>
> 2)storing the address informaion.
> this is a free form system that lets the complete address be stored
> in
> the components that make up an address.
>
> the basic part is the Addressline
> it has then name of the address line that is freefrom, this would be
> used to show on the UI and or the mailing piece.
> there is a  linenumber and lineposition. The line position lets
> complex
> addresses be define as separate components.
> Like the BR address line
> Postal Area--Postal District--Postal Sector--delivery Point
> with is you can also specify the separator and where to to put it.
>
> there are services that read the country formation information on a
> Create and put in a map for a UI.
> Service that Stores the data, win the free form format.
>
> These would override most of the data currently stored in the
> PostalAddress entity.
>
> any input?
>
>

[BJ Freeman]

in the international email system address1 and adddress2 as storage does
not allow for the complexity of other countries.
however the service that reads the stored data, will do the formating.
Since this is by country, the US freeform would be Address1, Address2,
city, state, postalcode.

Chris Howe sent the following on 12/29/2007 12:11 PM:

> Could you provide a bit more background.  My first instinct on this is
> to continue the storage as is (address1, address2) in freeform and to
> have services that read/transform that freeform into local conventions
> rather than storing them in local conventions.      
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> I am enhancing the PostalAddress.
>> there are two parts
>> 1)postal address specified by country.
>> This can be used to generate a screen to that country and do the
>> layout
>> for a mailing peice.
>> it also specifies how to store the address information.
>>
>> 2)storing the address informaion.
>> this is a free form system that lets the complete address be stored
>> in
>> the components that make up an address.
>>
>> the basic part is the Addressline
>> it has then name of the address line that is freefrom, this would be
>> used to show on the UI and or the mailing piece.
>> there is a  linenumber and lineposition. The line position lets
>> complex
>> addresses be define as separate components.
>> Like the BR address line
>> Postal Area--Postal District--Postal Sector--delivery Point
>> with is you can also specify the separator and where to to put it.
>>
>> there are services that read the country formation information on a
>> Create and put in a map for a UI.
>> Service that Stores the data, win the free form format.
>>
>> These would override most of the data currently stored in the
>> PostalAddress entity.
>>
>> any input?
>>
>>
>
>
>
>

[cjhowe]

Do you have a standards spec that can be used for reference?


--- BJ Freeman <[hidden email]> wrote:

> in the international email system address1 and adddress2 as storage
> does
> not allow for the complexity of other countries.
> however the service that reads the stored data, will do the
> formating.
> Since this is by country, the US freeform would be Address1,
> Address2,
> city, state, postalcode.
>
> Chris Howe sent the following on 12/29/2007 12:11 PM:
> > Could you provide a bit more background.  My first instinct on this
> is
> > to continue the storage as is (address1, address2) in freeform and
> to
> > have services that read/transform that freeform into local
> conventions
> > rather than storing them in local conventions.      
> >
> > --- BJ Freeman <[hidden email]> wrote:
> >
> >> I am enhancing the PostalAddress.
> >> there are two parts
> >> 1)postal address specified by country.
> >> This can be used to generate a screen to that country and do the
> >> layout
> >> for a mailing peice.
> >> it also specifies how to store the address information.
> >>
> >> 2)storing the address informaion.
> >> this is a free form system that lets the complete address be
> stored
> >> in
> >> the components that make up an address.
> >>
> >> the basic part is the Addressline
> >> it has then name of the address line that is freefrom, this would
> be
> >> used to show on the UI and or the mailing piece.
> >> there is a  linenumber and lineposition. The line position lets
> >> complex
> >> addresses be define as separate components.
> >> Like the BR address line
> >> Postal Area--Postal District--Postal Sector--delivery Point
> >> with is you can also specify the separator and where to to put it.
> >>
> >> there are services that read the country formation information on
> a
> >> Create and put in a map for a UI.
> >> Service that Stores the data, win the free form format.
> >>
> >> These would override most of the data currently stored in the
> >> PostalAddress entity.
> >>
> >> any input?
> >>
> >>
> >
> >
> >
> >
>
>

[BJ Freeman]

http://docs.ofbiz.org/display/OFBIZ/Extending+Postalthese entities is
fashioned after the xAL:2.0 Address Information


Chris Howe sent the following on 12/29/2007 12:37 PM:

> Do you have a standards spec that can be used for reference?
>
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> in the international email system address1 and adddress2 as storage
>> does
>> not allow for the complexity of other countries.
>> however the service that reads the stored data, will do the
>> formating.
>> Since this is by country, the US freeform would be Address1,
>> Address2,
>> city, state, postalcode.
>>
>> Chris Howe sent the following on 12/29/2007 12:11 PM:
>>> Could you provide a bit more background.  My first instinct on this
>> is
>>> to continue the storage as is (address1, address2) in freeform and
>> to
>>> have services that read/transform that freeform into local
>> conventions
>>> rather than storing them in local conventions.      
>>>
>>> --- BJ Freeman <[hidden email]> wrote:
>>>
>>>> I am enhancing the PostalAddress.
>>>> there are two parts
>>>> 1)postal address specified by country.
>>>> This can be used to generate a screen to that country and do the
>>>> layout
>>>> for a mailing peice.
>>>> it also specifies how to store the address information.
>>>>
>>>> 2)storing the address informaion.
>>>> this is a free form system that lets the complete address be
>> stored
>>>> in
>>>> the components that make up an address.
>>>>
>>>> the basic part is the Addressline
>>>> it has then name of the address line that is freefrom, this would
>> be
>>>> used to show on the UI and or the mailing piece.
>>>> there is a  linenumber and lineposition. The line position lets
>>>> complex
>>>> addresses be define as separate components.
>>>> Like the BR address line
>>>> Postal Area--Postal District--Postal Sector--delivery Point
>>>> with is you can also specify the separator and where to to put it.
>>>>
>>>> there are services that read the country formation information on
>> a
>>>> Create and put in a map for a UI.
>>>> Service that Stores the data, win the free form format.
>>>>
>>>> These would override most of the data currently stored in the
>>>> PostalAddress entity.
>>>>
>>>> any input?
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>

[BJ Freeman]

opps sorry for the bad link
http://docs.ofbiz.org/display/OFBIZ/Extending+PostalAddress+Information

BJ Freeman sent the following on 12/29/2007 12:42 PM:

> http://docs.ofbiz.org/display/OFBIZ/Extending+Postalthese entities is
> fashioned after the xAL:2.0 Address Information
>
>
> Chris Howe sent the following on 12/29/2007 12:37 PM:
>> Do you have a standards spec that can be used for reference?
>>
>>
>> --- BJ Freeman <[hidden email]> wrote:
>>
>>> in the international email system address1 and adddress2 as storage
>>> does
>>> not allow for the complexity of other countries.
>>> however the service that reads the stored data, will do the
>>> formating.
>>> Since this is by country, the US freeform would be Address1,
>>> Address2,
>>> city, state, postalcode.
>>>
>>> Chris Howe sent the following on 12/29/2007 12:11 PM:
>>>> Could you provide a bit more background.  My first instinct on this
>>> is
>>>> to continue the storage as is (address1, address2) in freeform and
>>> to
>>>> have services that read/transform that freeform into local
>>> conventions
>>>> rather than storing them in local conventions.      
>>>>
>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>
>>>>> I am enhancing the PostalAddress.
>>>>> there are two parts
>>>>> 1)postal address specified by country.
>>>>> This can be used to generate a screen to that country and do the
>>>>> layout
>>>>> for a mailing peice.
>>>>> it also specifies how to store the address information.
>>>>>
>>>>> 2)storing the address informaion.
>>>>> this is a free form system that lets the complete address be
>>> stored
>>>>> in
>>>>> the components that make up an address.
>>>>>
>>>>> the basic part is the Addressline
>>>>> it has then name of the address line that is freefrom, this would
>>> be
>>>>> used to show on the UI and or the mailing piece.
>>>>> there is a  linenumber and lineposition. The line position lets
>>>>> complex
>>>>> addresses be define as separate components.
>>>>> Like the BR address line
>>>>> Postal Area--Postal District--Postal Sector--delivery Point
>>>>> with is you can also specify the separator and where to to put it.
>>>>>
>>>>> there are services that read the country formation information on
>>> a
>>>>> Create and put in a map for a UI.
>>>>> Service that Stores the data, win the free form format.
>>>>>
>>>>> These would override most of the data currently stored in the
>>>>> PostalAddress entity.
>>>>>
>>>>> any input?
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>

[jonwimp]

BJ,

Very interesting!

Just wondering, are the Data Model Resource Books using this CIQ standard?

Would be nice if OFBiz data structure can do the CIQ thing.

Curiously, OFBiz data structure already doesn't follow some of the most vital guidelines in the
Data Model Resource books, like the system-independent numeric ID field and company-specific ID
like orderID of "WS<number>". Still don't know why, except guess that it might be due to
difficulty in crafting data-loading procedures for seed data.

Jonathon

BJ Freeman wrote:

> opps sorry for the bad link
> http://docs.ofbiz.org/display/OFBIZ/Extending+PostalAddress+Information
>
> BJ Freeman sent the following on 12/29/2007 12:42 PM:
>> http://docs.ofbiz.org/display/OFBIZ/Extending+Postalthese entities is
>> fashioned after the xAL:2.0 Address Information
>>
>>
>> Chris Howe sent the following on 12/29/2007 12:37 PM:
>>> Do you have a standards spec that can be used for reference?
>>>
>>>
>>> --- BJ Freeman <[hidden email]> wrote:
>>>
>>>> in the international email system address1 and adddress2 as storage
>>>> does
>>>> not allow for the complexity of other countries.
>>>> however the service that reads the stored data, will do the
>>>> formating.
>>>> Since this is by country, the US freeform would be Address1,
>>>> Address2,
>>>> city, state, postalcode.
>>>>
>>>> Chris Howe sent the following on 12/29/2007 12:11 PM:
>>>>> Could you provide a bit more background.  My first instinct on this
>>>> is
>>>>> to continue the storage as is (address1, address2) in freeform and
>>>> to
>>>>> have services that read/transform that freeform into local
>>>> conventions
>>>>> rather than storing them in local conventions.      
>>>>>
>>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>>
>>>>>> I am enhancing the PostalAddress.
>>>>>> there are two parts
>>>>>> 1)postal address specified by country.
>>>>>> This can be used to generate a screen to that country and do the
>>>>>> layout
>>>>>> for a mailing peice.
>>>>>> it also specifies how to store the address information.
>>>>>>
>>>>>> 2)storing the address informaion.
>>>>>> this is a free form system that lets the complete address be
>>>> stored
>>>>>> in
>>>>>> the components that make up an address.
>>>>>>
>>>>>> the basic part is the Addressline
>>>>>> it has then name of the address line that is freefrom, this would
>>>> be
>>>>>> used to show on the UI and or the mailing piece.
>>>>>> there is a  linenumber and lineposition. The line position lets
>>>>>> complex
>>>>>> addresses be define as separate components.
>>>>>> Like the BR address line
>>>>>> Postal Area--Postal District--Postal Sector--delivery Point
>>>>>> with is you can also specify the separator and where to to put it.
>>>>>>
>>>>>> there are services that read the country formation information on
>>>> a
>>>>>> Create and put in a map for a UI.
>>>>>> Service that Stores the data, win the free form format.
>>>>>>
>>>>>> These would override most of the data currently stored in the
>>>>>> PostalAddress entity.
>>>>>>
>>>>>> any input?
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>

[BJ Freeman]

Jonathon, Guess I will have to write one.. LOL
Just so people can have book to say it is a valid system.
:)
using a string as a ID to me is very system independent.
if it were a number (integer, long) then I would agree with you.
and there is a ProductStore Prefix that is appended to the order.
also there is a OAGIS project in the specialpurpose folder.

so if you clear up why you said these thing, I would be interested.

Jonathon -- Improov sent the following on 12/29/2007 7:07 PM:

> BJ,
>
> Very interesting!
>
> Just wondering, are the Data Model Resource Books using this CIQ standard?
>
> Would be nice if OFBiz data structure can do the CIQ thing.
>
> Curiously, OFBiz data structure already doesn't follow some of the most
> vital guidelines in the Data Model Resource books, like the
> system-independent numeric ID field and company-specific ID like orderID
> of "WS<number>". Still don't know why, except guess that it might be due
> to difficulty in crafting data-loading procedures for seed data.
>
> Jonathon
>
> BJ Freeman wrote:
>> opps sorry for the bad link
>> http://docs.ofbiz.org/display/OFBIZ/Extending+PostalAddress+Information
>>
>> BJ Freeman sent the following on 12/29/2007 12:42 PM:
>>> http://docs.ofbiz.org/display/OFBIZ/Extending+Postalthese entities is
>>> fashioned after the xAL:2.0 Address Information
>>>
>>>
>>> Chris Howe sent the following on 12/29/2007 12:37 PM:
>>>> Do you have a standards spec that can be used for reference?
>>>>
>>>>
>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>
>>>>> in the international email system address1 and adddress2 as storage
>>>>> does
>>>>> not allow for the complexity of other countries.
>>>>> however the service that reads the stored data, will do the
>>>>> formating.
>>>>> Since this is by country, the US freeform would be Address1,
>>>>> Address2,
>>>>> city, state, postalcode.
>>>>>
>>>>> Chris Howe sent the following on 12/29/2007 12:11 PM:
>>>>>> Could you provide a bit more background.  My first instinct on this
>>>>> is
>>>>>> to continue the storage as is (address1, address2) in freeform and
>>>>> to
>>>>>> have services that read/transform that freeform into local
>>>>> conventions
>>>>>> rather than storing them in local conventions.    
>>>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>>>
>>>>>>> I am enhancing the PostalAddress.
>>>>>>> there are two parts
>>>>>>> 1)postal address specified by country.
>>>>>>> This can be used to generate a screen to that country and do the
>>>>>>> layout
>>>>>>> for a mailing peice.
>>>>>>> it also specifies how to store the address information.
>>>>>>>
>>>>>>> 2)storing the address informaion.
>>>>>>> this is a free form system that lets the complete address be
>>>>> stored
>>>>>>> in
>>>>>>> the components that make up an address.
>>>>>>>
>>>>>>> the basic part is the Addressline
>>>>>>> it has then name of the address line that is freefrom, this would
>>>>> be
>>>>>>> used to show on the UI and or the mailing piece.
>>>>>>> there is a  linenumber and lineposition. The line position lets
>>>>>>> complex
>>>>>>> addresses be define as separate components.
>>>>>>> Like the BR address line
>>>>>>> Postal Area--Postal District--Postal Sector--delivery Point
>>>>>>> with is you can also specify the separator and where to to put it.
>>>>>>>
>>>>>>> there are services that read the country formation information on
>>>>> a
>>>>>>> Create and put in a map for a UI.
>>>>>>> Service that Stores the data, win the free form format.
>>>>>>>
>>>>>>> These would override most of the data currently stored in the
>>>>>>> PostalAddress entity.
>>>>>>>
>>>>>>> any input?
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>

[BJ Freeman]

BTW I have the entities that support this.
I will submit them if there is enough interest


Jonathon -- Improov sent the following on 12/29/2007 7:07 PM:

> BJ,
>
> Very interesting!
>
> Just wondering, are the Data Model Resource Books using this CIQ standard?
>
> Would be nice if OFBiz data structure can do the CIQ thing.
>
> Curiously, OFBiz data structure already doesn't follow some of the most
> vital guidelines in the Data Model Resource books, like the
> system-independent numeric ID field and company-specific ID like orderID
> of "WS<number>". Still don't know why, except guess that it might be due
> to difficulty in crafting data-loading procedures for seed data.
>
> Jonathon
>
> BJ Freeman wrote:
>> opps sorry for the bad link
>> http://docs.ofbiz.org/display/OFBIZ/Extending+PostalAddress+Information
>>
>> BJ Freeman sent the following on 12/29/2007 12:42 PM:
>>> http://docs.ofbiz.org/display/OFBIZ/Extending+Postalthese entities is
>>> fashioned after the xAL:2.0 Address Information
>>>
>>>
>>> Chris Howe sent the following on 12/29/2007 12:37 PM:
>>>> Do you have a standards spec that can be used for reference?
>>>>
>>>>
>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>
>>>>> in the international email system address1 and adddress2 as storage
>>>>> does
>>>>> not allow for the complexity of other countries.
>>>>> however the service that reads the stored data, will do the
>>>>> formating.
>>>>> Since this is by country, the US freeform would be Address1,
>>>>> Address2,
>>>>> city, state, postalcode.
>>>>>
>>>>> Chris Howe sent the following on 12/29/2007 12:11 PM:
>>>>>> Could you provide a bit more background.  My first instinct on this
>>>>> is
>>>>>> to continue the storage as is (address1, address2) in freeform and
>>>>> to
>>>>>> have services that read/transform that freeform into local
>>>>> conventions
>>>>>> rather than storing them in local conventions.    
>>>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>>>
>>>>>>> I am enhancing the PostalAddress.
>>>>>>> there are two parts
>>>>>>> 1)postal address specified by country.
>>>>>>> This can be used to generate a screen to that country and do the
>>>>>>> layout
>>>>>>> for a mailing peice.
>>>>>>> it also specifies how to store the address information.
>>>>>>>
>>>>>>> 2)storing the address informaion.
>>>>>>> this is a free form system that lets the complete address be
>>>>> stored
>>>>>>> in
>>>>>>> the components that make up an address.
>>>>>>>
>>>>>>> the basic part is the Addressline
>>>>>>> it has then name of the address line that is freefrom, this would
>>>>> be
>>>>>>> used to show on the UI and or the mailing piece.
>>>>>>> there is a  linenumber and lineposition. The line position lets
>>>>>>> complex
>>>>>>> addresses be define as separate components.
>>>>>>> Like the BR address line
>>>>>>> Postal Area--Postal District--Postal Sector--delivery Point
>>>>>>> with is you can also specify the separator and where to to put it.
>>>>>>>
>>>>>>> there are services that read the country formation information on
>>>>> a
>>>>>>> Create and put in a map for a UI.
>>>>>>> Service that Stores the data, win the free form format.
>>>>>>>
>>>>>>> These would override most of the data currently stored in the
>>>>>>> PostalAddress entity.
>>>>>>>
>>>>>>> any input?
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>