OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [oic] RE: mail merge interop ?


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.

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.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]