DITA Proposed Feature #4

Use OASIS xNAL standard element names for names and addresses

Longer description

DITA 1.0 doesn't include a domain to specifically describe names or addresses, either of persons or of organizations. The bkinfo topic specialization distributed in connection with bookmap in the DITA Open Toolkit includes descriptions of these types of content. However, this may not be the best way. A couple of suggestions have been made, representing two avenues of development:

putting all the elements related to describing names and addresses (and probably phone numbers?) into their own domain specialization. The most common usage of this domain would be in 'formal' types of documents such as books and articles which require information about the author and /or publisher.
aligning the DITA definitions of name and address-related elements with the OASIS xNAL name and address specifications. There is currently no alignment between the two sets.

To be precise, this proposal does not suggests an addaption of the xNAL element and attribute model. It just suggests to use element names and structures for addresses and names based on an existing standard (xNAL) instead of inventing something new. Following the the keep-it-simple rule, those elements should be used only, which are required in a bkinfo specialization.

A deeper integration of xNAL must be investigated and will be postponed to the post 1.1 time.

Scope

Major for either part of the proposal. However, adopting the xNAL model and working out how to model that within a DITA framework would be a much bigger effort than simply moving the current model into its own specialization. So investigations on that approach will be part of post DITA 1.1.

Creating a domain specialization with roughly the same set of elements currently defined in bkinfo would represent some design work, but not a great deal. Creating a domain specialization for names and addresses that used element names and structures derived from xNAL will require a great deal of design work. Since the content models used by xNAL are in many cases very different from the ones used by corresponding elements in bkinfo, a good balanced must be found between xNAL compliance and reasonability.

Use Cases

Use Case 1: Encapsulating name/location information within its own domain specialization: This encapsulation would enable name and location information to be used as metadata wherever appropriate. (It might be appropriate to include, as part of 'location' information, phone/fax numbers and Internet addresses as well.) This information could be reused in a variety of information types, books, newspaper or magazine articles, etc.,
Use Case 2: redesigning name/address information to map to xNAL specification: After this type of redesign, which would presumably include encapsulation of the data in a domain specialization, DITA name/location data could be exchanged more easy with customer service applications using the xNAL standard

Technical Requirements

Creating a separate specialized domain for the "DITA-xNAL" environment,
reducing xNL and xAL to a reasonable volume for bkinfo,
creation of a mapping table from the existing definition to xNAL (to ensure everything is covered in a reasonable way),
checking potential specialization to meet full xNAL correspondents, (post 1.1)
writing a language reference document for these new elements,

Costs

As the xNAL standard is already defined in detail, step 1 - 3 should not cost to much of working time, a couple of days maximum. Step 4 will need some time by an DITA expert. And step 5 depends on the number of elements taken in account.

Benefits

What is the need to explain the benefits of following an OASIS standard to an OASIS standartisation team? As described above, adopting the full xNAL standard is an overkill. But following a subset of it will ease data exchange.

Time Required

Step 1 - 3 : 5 days

Step 4: must be estimated

Step 5: depends on number of elements

Meetings: 2 - 3 meetings of 1 h