[tei-council] correspDesc proposal: some feedback.

[Martin Holmes]

I've made a comment on the Corresp sig, suggesting that rather than 
<cd:sender>, <ct:addressee> etc., <ct:party role="sender"> might be 
better because there are many more types of participant, as shown in the 
discussion there.

On James's point:

> <ct:transmission> – seems generally reasonable to me but I worry
> isn't sophisicated enough. Any transmission may have multiple
> stages of transmission. (I hand write you a letter, someone types
> it up for me, they send it by fax, someone takes the fax printout
> and puts in in an envelope, where some hotel staff deliver it to
> you while you sip margaritas.) So either one uses multiple
> transmission elements or it has a need for more structure inside
> it for different stages of transmission.  As far as I can
> conceive any stage in transmission might have a change of three
> major parts, the format/material of the correspondence (paper,
> MIME, smoke), the method of delivery (postal delivery, email,
> smoke signalling relay), and the agency responsible (courier
> company, a person, etc.). As well also each has changes in
> dateTime or location  –  so this might benefit from more structure.

Perhaps <ct:transmission> should nest?

Cheers,
Martin

On 14-08-01 04:04 AM, James Cummings wrote:
> 	
> Since we are all tasked with providing feedback on the
> correspDesc proposals
> http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml#Correspondence
> by 1 august.
>
> Here are my brief thoughts, some of which we discussed at the
> face to face meeting.
>
> I would separate discussion of correspDesc for detailed data
> capture and have a later customisation of this for an interchange
> format.  I think the interchange format is a good idea, but
> doesn't need to muddy the water for initial proposals to change
> the TEI. (A question is whether this interchange format should
> also be documented in the guidelines or not. I'm undecided about
> that.)
>
> As discussed at the face to face, a number of the proposed
> elements are very similar to existing TEI elements. I do feel
> Council should resist the addition of new elements where not
> necessary to stop overall bloat of the TEI. This does not mean we
> shouldn't add new elements, but just that the case for them needs
> to be clearly made, especially when existing elements might be
> used, or modified to include new uses.
>
> 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">
> <ct:placeAddressee> = <placeName role="addressee">
> <ct:correspClass> = <keywords>  (using inside <ct:correspDesc>
> gives heirarchy to know it is relating to correspondence.)
>
> <ct:correspDesc> – This generally makes sense as an enclosing
> element. Having option for model.pLike+ makes sense and is in
> keeping with general TE structured vs unstructured descriptions.
>
> <ct:transmission> – seems generally reasonable to me but I worry
> isn't sophisicated enough. Any transmission may have multiple
> stages of transmission. (I hand write you a letter, someone types
> it up for me, they send it by fax, someone takes the fax printout
> and puts in in an envelope, where some hotel staff deliver it to
> you while you sip margaritas.) So either one uses multiple
> transmission elements or it has a need for more structure inside
> it for different stages of transmission.  As far as I can
> conceive any stage in transmission might have a change of three
> major parts, the format/material of the correspondence (paper,
> MIME, smoke), the method of delivery (postal delivery, email,
> smoke signalling relay), and the agency responsible (courier
> company, a person, etc.). As well also each has changes in
> dateTime or location  –  so this might benefit from more structure.
>
> <ct:context> maybe appropriate existing mechanisms for standoff
> but not sure, otherwise generally looks ok. I'm assuming content
> model of correspDesc means context repeatable for multiple
> contexts. While one could use context/ref/date, is there a need
> for context to claim membership of att.datable?
>
> Those are the thoughts that occurred to me while rereading the
> proposal in github.
>
> -James
>