[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oic] RE: mail merge interop ?
On Tue, 2 Jun 2009, robert_weir@us.ibm.com wrote: > A side point -- I was at a conference in South Africa last year and saw a > presentation on their efforts to standardize address formats for the > country. The standard, which was still under development, identified > something like 31 different address forms, and this is a country with 11 > official languages! So I'm wary of trying to tackle this problem for the > entire world. I'm pretty sure there are at least 31 (would be) standards, and indeed, many countries use multiple "standard" address forms for different application domains. I cataloged some of the standards efforts here: http://xml.coverpages.org/namesAndAddresses.html > > However, there are four approaches to this, and similar problems, that are > worth thinking about: > > 1) Do nothing and leave it all to be application defined. > > 2) Attempt to define identifiers and semantics for all possible address > formats in use in the world. We know that this is fragile, and would need > to deal with all sorts of weird conventions, from poste restante to APO > address and so on. > > 3) Adopt a declarative approach where the standard defines a set of > spanning capabilities that are declared in a document, that put together > can express all address formats, known and unknown. A good start would > be the Universal Postal Union's UPU S42 "International Postal Address > Components and Templates" standard, which defines the "smallest meaningful > parts of names and addresses" > > 4) Generalize this even further by realizing that "mail merge" is really > "date merge" and has nothing fundamental to do with address, aside from > that being a conventional use. Obviously interoperability of data merge, > in the general case, requires interoperability of data bindings, etc. And > that isn't likely to happen. I would not expect that a > document/application bound to my database (with my credentials) would work > on your machine, using a different editor, but more importantly, not > having access to my database. I'm not saying this could not be made to > work, but it further out there, in terms of common document exchange > scenarios. That suggestion seems to have a lot of merit. I think it could be a big win if an ODF module would provide support for minimal merge (data merge) based upon e.g., a very simple notion of e.g., VCARD address subset. Since I've not followed this thread to date, and don't know what functionality is already supported by the spec/software, I'd best stop there. Summary: something simple might be better than nothing. - Robin Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/who/staff.php#cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 > > -Rob > > > "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/02/2009 > 06:29:09 PM: > >> From: >> >> "Dennis E. Hamilton" <dennis.hamilton@acm.org> >> >> To: >> >> <Bernd.Eilers@Sun.COM>, <oic@lists.oasis-open.org> >> >> Date: >> >> 06/02/2009 06:31 PM >> >> Subject: >> >> RE: [oic] RE: mail merge interop ? >> >> Based on this report from Bernd, I am inclined to think that a MailMerge >> scenario is not a very good interoperability case. It is more of an >> application feature case and I think we should stay clear of that. >> >> It seems to me that if there were an interoperability case, it would > have to >> do with the electronic receipt of the resulting documents and how the >> populated fields show up. But I think this might be rather far-fetched. >> >> Perhaps an alternative, moderate scenario would be a turn-around > document >> that has fields that need to be entered and the document then returned > to >> the originator. (I just ran into one of those, a US Internal Revenue >> Service Form W-9 in a PDF that had fields for entering of taxpayer >> information. There was no way to fill in my signature though, so I > ended up >> printing the populated document, signing the paper copy, and scanning > that >> one in for electronic submission [;<). >> >> The reusability of a mail-merge template document might be of interest, > but >> I wonder if this is high-hanging fruit considering how the merge process > is >> so implementation based? >> >> - Dennis >> >> -----Original Message----- >> From: Bernd.Eilers@Sun.COM [mailto:Bernd.Eilers@Sun.COM] >> Sent: Tuesday, June 02, 2009 05:39 >> To: oic@lists.oasis-open.org >> Subject: Re: [oic] RE: mail merge interop ? >> >> >> Hi there! >> >> > [... snip ...] >> >>> PS: action point: check how mailmerge is done in your favorite >> ODF-applications ;-) >>> >>> >> >> OpenOffice.org uses Database Fields in an ODF document template as >> specified in Section 6.6 of Open Document Format for Office Applications > >> (OpenDocument)v1.2 >> > http://www.oasis-open.org/committees/download.php/32431/OpenDocument-v1.2-cd > >> 02.odt >> >> >> MailMerge in OpenOffice.org is bascially done by OpenOffice.org >> iterating through the rows of a connected database source, filling out >> DataBaseFields of a template document with data. There is a fixed set of > >> address fields the OpenOffie.org MailMergeWizard knows about which is >> matching those to fields of the database source, eg. an address book. >> The Default Settings are such that the database source columns are >> expected to have the same names as those address fields in the >> mail-merge-wizard but different mappings can be configured also. >> >> Basically you can say that there is nothing specific to a mail merge >> operation defined in the ODF Specification and that a mail-merge feature > >> for an ODF Application would be just a very special kind of usage of the > >> database fields concept of ODF. >> >> So Interoperability here is IMHO not an issue of the completness of the >> ODF Support / ODF Interoperatbility for an ODF-Application here but >> merly an Application compatibility Issue outside the scope of ODF >> Interoperability. For example there may be an issue of using >> compatible/non-compatible address field names in template documents used > >> by MailMerge features. And than there may be an issue of which types of >> database sources the applications do support. >> >> Kind regards, >> Bernd Eilers >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]