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