[tei-council] [TEI-CORRESP-SIG] correspDesc proposal: some feedback.

[Martin Holmes]

I take Peter's point that there is some justification for syntactic 
sugar elements here. However, I'm not sure that we need such a 
proliferation of them. I made this suggestion on the tei-corresp-sig 
list, and I still think it's worth considering:

There's a large number of different potential parties to a 
correspondence, including sender, recipient, addressee (these two may 
differ), signer, co-signer, typist, etc. This list is potentially very 
long, but there are some core roles which we know about. My suggestion 
was to create a single new element:

<ct:party> (or perhaps <ct:correspParty>)

with @role to differentiate them. The Guidelines could provide a 
suggested value list covering all the core, known requirements (sender, 
recipient etc.) and yet still allow for further extension. 
Interoperability would be served by the suggested values being 
formalized in the interchange format.

<ct:party role="addressee"><persName>...</persName></ct:party>

<ct:party role="unintended-recipient"><persName>...</persName></ct:party>

<ct:party role="snoop"><persName>...</persName></ct:party>

You could have @role=

     author
     sender
     signer
     co-signer
     ...

and of course you could have <orgName> and so on in place of <persName> 
in the content of <ct:party>.

This seems more straightforward to me than arguing about which roles 
deserve their own syntactic sugar elements and which don't.

Cheers,
Martin

On 14-08-20 08:06 AM, Peter Stadler wrote:
> Dear all,
>
> thanks for all the feedback so far (on Council list and here). I know
> I’m late but wanted to elaborate on some issues that were raised.
> First, there are concerns about the multitude of new elements which
> look like syntactic sugar for existing elements:
>
> Am 01.08.2014 um 13:04 schrieb James Cummings
> <James.Cummings at it.ox.ac.uk>:
>
>> Possibilities for using existing TEI elements: <ct:sender> =
>> <persName role="sender"> <ct:dateSender> = <date type="sender">
>> <ct:placeSender> = <placeName role="sender"> <ct:addressee> =
>> <persName role="addressee"> <ct:dateAddressee> = <date
>> type="delievery">
>
> Yes. True. It is syntactic sugar. BUT: The fundamental difference is
> that these elements are specifically designed for meta data which is
> usually more constrained than those elements that can occur within
> running text. E.g. <editor> or <author> are very similar in this
> respect to our <ct:sender>, being somehow syntactic sugar for
> <persName role=„editor|author|sender“> but with only a subset of
> attribute classes and a limited usage (i.e. the contexts in which
> those elements may occur). I’m not trying to say „Because we have
> <editor> I want <sender>“ but want to make the point that <ct:sender>
> is not like <persName>, rather it’s more like
> <editor|author|principal|…>. Having a clear divide between metadata
> elements and text elements is IMHO a very good thing as other
> discussions [1] have already shown.
>
> Syd proposed to keep <ct:sender> and <ct:addressee> but to subsume
> all respective information (place, date, persname) there and make use
> of established elements, e.g. <ct:sender> <persName
> ref="people.xml#sbauman.emt"/> <date when="2014-07-07"/> <location>
> <geo>41.827428 71.400503</geo> </location> </ct:sender> That’s a
> little bit better but facilitates not that level of interoperability
> I’d like to have — and I disagree with Syd because I not only  think
> it’s possible to achieve interoperability but that it’s our duty to
> provide interoperability on the meta data level (and not touch the
> freedom of encoding of text)! So, Syd’s proposal is more like a
> <senderDesc>, kind of a box of chocolates — you never know what you
> get, making it really hard to process …
>
> Enough for now, thanks to everyone who made it here, best Peter
>
>
> [1]
> http://lists.village.virginia.edu/pipermail/tei-council/2014/019369.html
>