How to include xNAL in bookmap

Decisions:

This should be done as a domain. We're proceeding as a domain to see if any snags come up. All XNAL information will be inside <authorinformation>, which is a domain specialization of the new <data> element.
We will not use all of the XNAL names; we will use a subset that use XNAL names where possible, and can map directly to XNAL.
Most elements in the old bookmap that included person, address, organizationname, etc, can all reasonably take the <authorinformation> element as a container for the same content. This also makes it easy to add the domain.
Elements will use lower case.
If XNAL information is necessary that usually goes into attributes, we will create specialized DITA elements (has not come up yet)
XNAL has a simple phone ContactNumber element, with a free-form attribute to list the type. We will use specific elements, and leave in contactnumber so users could specialize a new phone type.
The <contact> info no longer makes sense with the XNAL markup, because there is already contact information available with any person or organization. So, it's been removed.
The <affiliations> and <phone> elements have been removed for similar reasons.
Note: This is going to be handled as a domain. If the domain is added to base topics, authorinformation will be available anyplace that <data> is allowed, which is virtually anywhere. Thus, it is 'not' a good idea to add this domain into base topics at this time. For future releases of DITA, there are ideas about how to add domains with constraints, which could restrict this to the topic prolog; at that time it will make sense to reuse this domain in topics.
The above disclaimer does not mean that domains with constraints will make current implementations backwards-incompatible. Bookmap will continue to include the domain in the same way. Topics that choose to may include the domain today, and do so in the future. Users that wait may add this domain, using constraints, when that is possible.

Questions:

XNAL uses a (firstname*, middlename*, lastname*) model, with an attribute that lets you specify whether the name is a given name, surname, family name, etc. Bookmap currently uses (givenname*, middlename*, familyname*) model. Without the attribute distinctions, should we switch to XNAL?
When <person> becomes <personname>, it loses address, resource, and summary. Address is available after personname. Where should the other 2 go, if they are still needed?
In the XNAL model, <addressdetails> can only contain one child. So, to specify the throughfare, locality, administrativearea, and postalcode, you would need 4 addressdetails wrappers. Can we allow all of these in a single element? Any conversion to XNAL could break them apart.
Contact information (address, phone, email) is now a peer of the person name, and cannot be specified inside the person information. Are there any problems with this? And a related question...
Should authorinformation only allow one (personname, organizationname) to make it clear that the contact info goes with a single person/organization? Or is it a good idea to list 2 authors in one <authorinformation> wrapper, if the address is the same? In that case, the email and phone may still be unclear.
Several elements that XNAL uses, which are not yet in the domain, are listed in italics below. We need to determine which, if any, to add.

New markup

The authorinformation element will appear where the data element appears, inside both bookmeta and topicmeta. It will have the following structure, based on suggestions from Chris Kravogel:

Element: bookmeta
- Element: authorinformation
  - Element: OrganizationNameDetails: this element was not added, because I cannot find it in the XNAL definitions. Is it intended to contain anything other than organizationname?
  - Element: organizationname [was 'orgname'; content model changes from (address, phone, etc) to ph.cnt]
  - Element: personname [was 'person' in old bookmap; content model removes address, phone, summary, etc, most of which come later]
    - Element: nameline: not yet added - do we need it?
    - Element: preceedingtitle [new element; in XNAL, used for titles such as His Excellency; do we need this?]
    - Element: honorific: [same as old bookmap; XNAL uses <title> but we cannot reuse that element name]
    - Element: givenname [same as old bookmap: XNAL uses <FirstName>, see question above]
    - Element: middlename [same as old bookmap]
    - Element: nameprefix: not added yet, should we add it? Used for prefixes such as de, van, etc
    - Element: familyname [same as old bookmap: XNAL uses <lastname>, see question above]
    - Element: othername: not added yet, should we add it?
    - Element: alias: not added yet
    - Element: generationidentifier [was 'lineage' in old bookmap]
    - Element: Suffix: not added yet
    - Element: otherinfo [same as old bookmap]
  - Element: addressdetails [new wrapper element]
    - Element: address ['significantly changed from bookmap;' it was a container for all address information, to match XNAL it becomes a plain text field with specific values to follow]
    - Element: AddressLines: not added yet. It would contain (addressline+) which is a single line of an address, with no other information. Is this needed?
    - Element: country [same as old bookmap, but outside of <address>]
    - Element: administrativearea [Similar to 'stateprov' in old bookmap, except that this could also encompass additional information, such as counties or special administrative areas within a country]
    - Element: locality [Similar to 'city' in old bookmap, but can reference any built-up area]
    - Element: throughfare [new element coming from XNAL, for a street name]
    - Element: postalcode ['Not a part of XNAL:' we have it today, and I expect we do not want to lose it?]
  - Element: personinfo: was suggested as a container for the following elements, but does not seem to match the usage in XNAL, so I'v left it out for now
  - Element: contactnumbers [New container element for phone information]
    - Elements: (officephone*, fax*, cellular*, urlphone*) [same as old bookmap, with URLPhone now urlphone]
    - Element: contactnumber [The generic XNAL element, can be specialized for additional phone types]
  - Element: emailaddresses [New container element]
    - Element: emailzddress [New elment]

Older info:

Some snags have been encountered while trying to integrate xNAL conventions into bookmap. There are a couple of open thoughts.

Looking at the xNAL standard, there are a lot of elements not listed in the table below. Do we need to include those as well, or are we simply trying to reuse xNAL naming for the elements we do want?

- I would recommend to use a simple base set of elements. The intention was to use xNAL instead of "self created" names and elements. But I guess there is no need to go deeper. Would it be possible that someone can specialize it into a deeper xNAL structure?

There are several meta elements for this information already. This table presents the current elements and suggested xNAL equivalents, from Christian Kravogel (the plus signs are there to indent and show nesting, because the Wiki doesn't preserve spaces):

Current version	xNAL version
* Element: bookmeta	* Element: bookmeta
+* Element: authorInformation	+* Element: authorInformation
++* Element: contact	++* Element: OrganizationNameDetails
++* Element: organization	+++* Element: OrganizationName
+++* Element: orgname	++* Element: PersonName
++* Element: person	+++* Element: NameLine
+++* Element: address	+++* Element: PreceedingTitle
++++* Element: city	+++* Element: Title
++++* Element: country	+++* Element: FirstName
++++* Element: postalcode	+++* Element: MiddleName
++++* Element: stateprov	+++* Element: NamePrefix
+++* Element: affiliations	+++* Element: LastName
+++* Element: familyname	+++* Element: OtherName
+++* Element: givenname	+++* Element: Alias
+++* Element: honorific	+++* Element: GenerationIdentifier
+++* Element: lineage	+++* Element: Suffix
+++* Element: middlename	+++* Element: otherinfo
+++* Element: otherinfo	++* Element: AddressDetails
+++* Element: phone	+++* Element: Address
++++* Element: cellular	+++* Element: AddressLines
++++* Element: fax	+++* Element: Country
++++* Element: officePhone	+++* Element: AdministrativeArea
++++* Element: URLPhone	+++* Element: Locality
+++* Element: resource	+++* Element: Throughfare
	++* Element: PersonInfo
	+++* Element: ContactNumbers
	++++* Element: ContactNumber
	+++* Element: EmailAddresses
	++++* Element: EmailAddress

Questions to resolve:

Current implementation includes address as part of <person>. xNAL uses it as a peer. If we move it to a peer, then several models that use person should also get the address, but not all. For example, we will still need it in authorinformation and contact, but we will probably not need it in reviewer. We could just use the PersonName fragment in those locations.

- Here the same answer, just keep it simple as default (lowest common multiplyer) and try to enable more complexity via specialization.

Will bookmap users find all of the xNAL names intuitive? For example, NameLine and AddressLines?

- Maybe not, that one will need info from the reference guide. I am not realy sure about NameLine and AddressLines, they are providing just free text lines for names and addresses. It might be the source for specialization, e.g. via siplification to reduce the address element to AddressLine only or to use it to be specialized to more specific elements.

The xNAL definition has more extensive content models inside of these elements (for example AddressLines takes AddressLine+). How much of these do we want?

- Maybe none, keep it simple. If we can enable more complexity via specialization. If so we may can add a reference to the full xNAL standard into the reference guide.

OASIS-approved DITA elements have all used lower case so far. Bookmap is expected to do the same. Will it be a problem to use lower case for xNAL elements? If so, then that indicates we might want to use a domain for this.

- As DITA elements have all used lower case, we should keep lower case for xNAL elements as well.

Many of the xNAL elements use attributes - do we need to model the attributes in DITA? This could be done by storing them as elements.

- In my point of view that is maybe necessary in a few cases only, but maybe there are other opinions.

Questions about specific mappings, assuming xNAL will be integrated with bookmap:

bookmap currently includes many specify types of phone numbers, while xNAL uses only ContactNumber - do we want to keep the distinctions?

- The xNAL ContactNumber uses an attribute to specify which type of ContactNumber is mentioned. If we can not add this attribute, I guess that the best solution will be to use: contactnumbers +phone +fax etc.

How is Title different that PrecedingTitle? We cannot reuse the title element, because title is already a defined DITA element, which cannot be used inside this specialization - we would need to give it another name.

- I guess we can skipp title

xNAL does not have <contact> ... this presumably lists the author to be contacted? I am not sure about that though, because authorinformation itself is full of contact info.

- I did not understand the <contact> element in the first place. But maybe we should keep that.

bookmap current has an address that allows #PCDATA, plus elements to identify the city, state/province, postalcode, and country. xNAL does not seem to allow text in the addressDetails element; I am not sure how to map the existing semantics into Address and AddressLines vs. Country, AdministrativeArea, Locality, and Throughfare.

- I have to think of that point more in deep. No answer yet.