Yes. I agree. it would be a short term way of doing it. see my next email on embedded format.
Adrian Crum sent the following on 7/26/2008 12:49 PM: > I think my suggestion would accomplish both, without the need to change the > xsd or have sequence numbers. > > -Adrian > > --- On Sat, 7/26/08, BJ Freeman <[EMAIL PROTECTED]> wrote: > >> From: BJ Freeman <[EMAIL PROTECTED]> >> Subject: Re: Postal Address entity >> To: [email protected] >> Date: Saturday, July 26, 2008, 12:29 PM >> I also proposed a change to the entity.xsd that would put in >> output >> format per field. >> then the output would be drive by using output format >> with what I proposed just in the address, only need to sort >> by the >> sequence number to have correct line numbers >> for input there would have to be an entity in country that >> gave the >> address format >> >> >> Adrian Crum sent the following on 7/26/2008 11:41 AM: >>> As far as the UI is concerned, what about having an >> entity that ties a form widget name to a geo code? We could >> have something like CommonPostalAddressForms.xml that >> contains the various postal address layouts. Some work >> might need to be done in the form widget to give it the >> ability to include "form snippets." >>> -Adrian >>> >>> --- On Sat, 7/26/08, BJ Freeman >> <[EMAIL PROTECTED]> wrote: >>>> From: BJ Freeman <[EMAIL PROTECTED]> >>>> Subject: Re: Postal Address entity >>>> To: [email protected] >>>> Date: Saturday, July 26, 2008, 11:31 AM >>>> ooops >>>> <field name="postalCodeGeoId" >>>> type="id"></field> >>>> which would point to a entity Postalcode with a >> one to one >>>> would point to postalCodeLine with a one to one >>>> >>>> >>>> BJ Freeman sent the following on 7/26/2008 11:07 >> AM: >>>>> the Postal Address in the data book >>>>> has: >>>>> address1 >>>>> address1 >>>>> and >>>>> directions. >>>>> >>>>> the postaladdress entity has: >>>>> toName name >>>>> attnName name >>>>> >>>>> which to me should be using the postaladdress >> to >>>> PartyContactMech only >>>>> these should be removed >>>>> postalCode short-varchar >>>>> postalCodeExt short-varchar >>>>> and just use the >>>>> <field name="postalCodeGeoId" >>>> type="id"></field> >>>>> which would point to a entity Postalcode with >> a one to >>>> many (parent to >>>>> child) would point to postalCodeLine with a >> one to >>>> many (parent to child) >>>>> The reasoning for the refactor is the would >> like to >>>> change the >>>>> PostalAddress to point to a new Entity Address >> line >>>>> with a one to many (parent to child) relation >>>>> it would have a sequence number for getting >> the proper >>>> output. >>>>> this would allow flexibility that is used in >> other >>>> countries. >>>>> the Postal address would also point to new >> entity >>>> AddressDirections >>>>> David E Jones sent the following on 7/26/2008 >> 10:16 >>>> AM: >>>>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman >> wrote: >>>>>>> the databook figure 2.8 has it the way >> I >>>> figure it should be. >>>>>>> is there a reason it was implemented >> the way >>>> it was. >>>>>>> 1) postaladdress has party information >>>>>> Could you be more specific? >>>>>> >>>>>>> 2) it has Postal Code instead of being >> in the >>>> geography boundary >>>>>> It actually has both. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> > > > > > >
