[docbook-tc] xNAL, <personname>, & RFE 480957 (Name and address markup)

[Michael Smith <smith@xml-doc.org>]

I think Norm has added an item to the Dec 18 TC agenda in response to
a request from Ram Kumar of the OASIS Customer Information Quality
(CIQ) that we look at their "extensible Name and Address Language"
(xNAL) DTD and see if/how it can be integrated with DocBook.

So I ran it through dtdt2html and posted the generated documentation
to my website for anybody who wants to review it before the telcon.

  http://www.logopoeia.com/xml/xNAL/

The address markup basically starts here:

  http://www.logopoeia.com/xml/xNAL/addressdetails.html

and if you click through it, you'll see it's quite complex. The
structure starts like this:

  addressdetails ::=
  ( deliveryidentifier * , ( address | addresslines | country
    | administrativearea | locality | thoroughfare ) ) 

and the content model for <locality> looks like this:

  locality ::=
  ( addresslines | ( localityname * , ( postbox | largemailuser
    | postoffice ) ? , thoroughfare ? , premise ? ,
    dependentlocality ? , postalcode ? ) )

and several of those child elements have a fairly complex content
models too.

For comparison purposes, the current DocBook <address> looks like:

  Address ::=
  (#PCDATA|Honorific|FirstName|Surname|Lineage|OtherName|
   Affiliation|AuthorBlurb|Contrib|Street|POB|Postcode|City|State|
   Country|Phone|Fax|Email|OtherAddr)*

Outside of Ram Kumar's general request that we review their xNAL DTD,
I don't think there's been a specific proposal from anyone to change
the <address> content model -- no as part of RFE 480957 at least.

Moving onto the "name" part of the xNAL DTD, their person-name markup
is at:

  http://www.logopoeia.com/xml/xNAL/personname.html

and compared to the address markup, looks a bit less complicated

  personname ::=
  ( precedingtitle * , title * , firstname * , middlename * ,
    lastnameprefix ? , lastname * , othername * , formername * ,
    alias * , generationidentifier * , suffix * , generalsuffix ? )

The content of most of those child elements is #PCDATA.

But it's still more complicated than the new DocBook <personname>
element that Norm has proposed as part of RFE 480957:

  personname ::=
  ((honorific|firstname|surname|lineage|othername)+)

Note that Norm's proposal is also that we change the content model for
<author> to this:

  author ::=
  ((personname, (personblurb|affiliation|email|address)*))

...with the main point of RFE 480957 seeming to be to provide a way to
associate email and address with <author>s (and <editor>s etc.?)
independent of their organizational affiliations.

If we add a <personname> element, it seems reasonable that a user
might want to use it within a normal <para> or whatever to mark up the
name of a person other than an <author> <author>, <collab>orator,
<editor>, or <othercredit> etc. -- that is, a person who may not even
have contributed at all to the creation of the document, but is simply
named in the document.

So, I went ahead a filed an RFE (491629) proposing that we either:

A. Add <personname> to %gen.char.class.

or

B. Create a <person> element with the same new content model as
   <author>, and add <person> (instead of <personname>) to
   %gen.char.class.

Regards,

  --Mike