Hi Nancy,
I looked at othercredit as well, but the enumerations of the class
attribute make more difficult to generalize and I'd rather not use role
unless absolutely necessary.
The author and editor tags are very specific, while person is much more
general. Perhaps an employee directory would be better handled with the
vCard standard, but since all of my client's other docs will be
standardizing on DocBook, it would be nice to use familiar tag sets and
structures.
This may, indeed, be out of scope. However, I would also like to see
this element added to provide additional flexibility for DocBook. The
periodical RFE was narrowing the scope of use, not adding
generalization/flexibility.
I'm not going to die on the sword for this one, as othercredit could
indeed be made to work, but I'm also afraid that the use I described
would actually be abusing the tag a bit. It also feels a little kludgy.
Best regards,
--Scott
Nancy P Harrison wrote:
>
> At the risk of roiling the waters...
>
> While I agree that the best way to make Scott's task easier is to have
> all the info in a 'person'-type element, rather than in the address
> element, I'm not sure how adding a person element fulfills our mission
> of supporting the delivery of technical documentation. At the meeting
> yesterday, we specifically rejected an RFE for being out-of-scope, and
> this request seems equally out-of-scope to me. If a company really
> wants to create an employee directory in DocBook, they already can,
> using [and maybe aliasing?] the 'othercredit' element, which matches
> author and editor in content.
>
> But I don't see how generic 'person' content is applicable to
> technical documentation. If we add person, we should also take
> another look at the RFE we rejected yesterday
>
> just my $.02
>
> Nancy
>
>
> "Dick Hamilton" <> wrote on 03/15/2006 08:58:40 PM:
>
> > I agree that it's a bit strange to have either authorblurb or
> > personblurb in address. I wonder why authorblurb ever ended
> > up there in the first place.
> >
> > I'd be more comfortable generalizing the higher level structure
> > (author, editor) to something like <person> and use an attribute
> > to identify the kind of person (author, editor, DocBook Geek).
> > Or add <person> with the same content model, which might be better
> > since author and editor are pretty deeply ingrained and (at least
> > author) probably used in nearly every document.
> >
> > Either option would make it possible to fully identify all sorts
> > of people and not add extra stuff to their addresses.
> >
> > Dick
> >
> >
> > > -----Original Message-----
> > > From: Scott Hudson [mailto:]
> > > Sent: Wednesday, March 15, 2006 11:39 AM
> > > To: Norman Walsh
> > > Cc:
> > > Subject: Re: [docbook-tc] personblurb in address?
> > >
> > >
> > > Here's my situation, IHAC that is standardizing on DocBook
> > > 4.5 and has a
> > > variety of publications. Most are very straightforward, but
> > > they would
> > > also like to publish their Employee Directory using DocBook.
> > > That means
> > > for each entry, there will be a name, address, phone, email, etc.
> > >
> > > They would also like to put in a biography and/or job
> > > description. This
> > > is where I thought personblurb would make the most sense, so the
> > > directory would look something like:
> > > <book>
> > > <title>Employee Directory</title>
> > > <chapter>
> > > <title>Communications Division</title>
> > > <address>
> > > <personname>
> > > <firstname>Scott</firstname><surname>Hudson</surname>
> > > </personname>
> > > <affiliation>
> > > <orgname>Flatirons Solutions</orgname>
> > > <orgdiv>Communications</orgdiv>
> > > </affiliation>
> > > <email></email>
> > > <phone>303-542-2146</phone>
> > > <fax>303-544-0522</fax>
> > > <street>4747 Table Mesa Drive, Suite 200</street>
> > > <city>Boulder</city> <state>CO</state> <postcode>80305</postcode>
> > > <authorblurb><para>Scott likes DocBook. He's a
> > > certifiable DocBook
> > > geek, and a member of the OASIS TC.</para></authorblurb>
> > > </address>
> > > </chapter>
> > > </book>
> > >
> > > Best regards,
> > >
> > > --Scott
> > >
> > > P.S., Plaxo is just a service I use. I got tired of maintining my
> > > addressbook in multiple places, and it syncs to Outlook and
> > > Thunderbird.
> > >
> > > Norman Walsh wrote:
> > > > / Scott Hudson <> was
> > > heard to say:
> > > > | according to http://docbook.org/tdg/en/html/address.html,
> > > authorblurb
> > > > | is allowed in address. Why is personblurb not also allowed (if the
> > > > | address is describing someone, say in an employee
> > > directory, rather
> > > > | than an author)?
> > > >
> > > > | Perhaps personblurb should be part of person.ident.mix?
> > > >
> > > > Both seem a little bizarre to me. Why is the blurb part of
> > > the address?
> > > > Note that in 5.0, neither is allowed.
> > > >
> > > > http://docbook.org/tdg5/en/html/address.html
> > > >
> > > > Allowing biblioref looks a bit odd in there but it's a
> > > consequence of
> > > > allowing link and xref. I'm not sure what I think about that.
> > > >
> > > > | /Add me to your address book.../
> > > > |
> > > <https://www.plaxo.com/add_me?u=17180023598&v0=298305&k0=537541243>
> > > >
> > > > Is plaxo a service that you're using personally, or something that
> > > > Flatiron uses? (Just curious.)
> > > >
> > > > Be seeing you,
> > > > norm
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > >
> > >
> > > Flatirons Solutions
> > > /*Vision. Experience. Engineering Excellence.*/
> > > <http://www.flatironssolutions.com>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *Scott Hudson*
> > > /Senior Consultant/
> > >
> > >
> > >
> > > *Flatirons Solutions*
> > > 4747 Table Mesa Drive Suite 200
> > > Boulder, CO 80305
> > > <http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=4747+Table+Mes
> > a+Drive+Suite+200&csz=Boulder%2C+CO+80305&country=us>
> >
> >
> >
> > <mailto:>
> > web:http://flatironssolutions.com <http://www.flatironssolutions.com>
> > blog:http://scottysengineeringlog.net
> >
> >
> >
> > tel:
> > fax:
> > mobile:
> >
> >
> >
> > 303-542-2146
> > 303-272-7069
> > 303-332-1883
> >
>
> ____
> Nancy Harrison
> IBM Rational Software
> Phone: 781-676-2535
>
--
Flatirons Solutions
/*Vision. Experience. Engineering Excellence.*/
<http://www.flatironssolutions.com>
*Scott Hudson*
/Senior Consultant/
*Flatirons Solutions*
4747 Table Mesa Drive Suite 200
Boulder, CO 80305
<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=4747+Table+Mesa+Drive+Suite+200&csz=Boulder%2C+CO+80305&country=us>
<mailto:>
web:http://flatironssolutions.com <http://www.flatironssolutions.com>
blog:http://scottysengineeringlog.net
tel:
fax:
mobile:
303-542-2146
303-272-7069
303-332-1883
/Add me to your address book.../
<https://www.plaxo.com/add_me?u=17180023598&v0=298305&k0=537541243>
/Want a signature like this?/ <http://www.plaxo.com/signature>
