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 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > > > > > > >
