[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: onomastical

• From: Burnard Towers <lou.burnard@c...>
• To: John Cowan <jcowan@r...>
• Date: Wed, 17 May 2000 23:17:21 +0100

At 14:06 17/05/00 -0400, you wrote:
>Lou Burnard wrote:
>
>> |Separate first-name and last-name elements are not good
internationalization,
>> |because some people don't have identifiable first names and last names,
>> |or if they do, they may not mean what you expect; e.g. Hungarian,
Japanese,
>> |and Chinese names have the family name first.
>> 
>> I would argue that au contraire separating first and last name
>> elements *is* good internationalization
>
>Separating surnames/sortnames is useful.  What I was actually criticizing
>was the terms "first name" and "last name" themselves.  Some people have the
>family name first, some last, and for some there is no identifiable
>"family name", as Icelanders and some Arabs.  Furthermore, having a
>content model (first-name, last-name) makes it hard to distinguish
>George Bush from George W. Bush.

I agree entirely with that! The point I was making (not very clearly I agree)
was only that it is good idea to separate the different components of a name.

>
>> Or maybe
>> <persName><surname>Murata</surname><givenName>Makoto</givenName></persName>
>
>Fine, but what about "David Oddson" (Prime Minister of Iceland), where
>"David" is a given name, "Oddson" is a patronymic, and the appropriate
>sort key is "David"?  Your markup either won't handle this or won't
>do what you want.  I represent it as <name><cname>David Oddson</cname>
><sname>David</sname></name>.

Your markup is excellent for the case where you want to represent two
things (a) the way a name should be sorted (b) the way a name should be
printed. You might also
achieve the same thing with a sort key attribute
<name sortas="David">David Oddson</name>
 
But is it really the case that the processing of names is exhausted by just
distinguishing a sort key and printable string? What the much maligned
baroque structure of the TEI Guidelines is trying to do is suggest ways of
representing components of a name, so that different applications  can do
different abritrary things things with them e.g. extract only names that
include patronymics, investigate numbr of given names, popularity of
Saints' names etc. Clearly some combinations will pose processing problems
but we dont do ourselves any favours by ignoring their existence on that
account.

>This may be adequate for mere document markup,
>but for processing (document or otherwise), we need to be able to
>handle every case somehow

Sorry, this doesnt make any sense to me. What's "mere" about document
markup? and why should it preclude being able to handle every case?
----------------------------------
>From The Desktop at Burnard Towers


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Follow-Ups:
  • Re: onomastical
    • From: John Cowan <jcowan@r...>

• References:
  • onomastical
    • From: Lou Burnard <lou.burnard@c...>
  • Re: onomastical
    • From: John Cowan <jcowan@r...>

• Prev by Date: Ambiguity in XML spec
• Next by Date: Re: Parse Error Not Thrown When Expected
• Previous by thread: Re: onomastical
• Next by thread: Re: onomastical
• Index(es):
  • Date
  • Thread