Simple schema allows <listPerson> but not <person>

[martindholmes]

Unless I'm missing something obvious, this is subtly cruel.

[martindholmes]

Also, how about having particDesc as a place to put the listPerson?

[martinmueller39]

Lou has a good point about mission creep. On the other hand, I'm beginning to think that "Simple" applies more to the element than to the header-a point that Sebastian has often made, I think. we may end up with important use cases where the encoding of the text is quite sparse, but there is a need for a lot of metadata. I ran into this yesterday when I tried to transform the Folger Shakespeare into TEI Simple. I ended up translating the Folger's particDesc from the header into a castList child of front. But that was lossy and struck me as unsatisfactory.

There is also and for recording values of ana attributes in a stand-off fashion. With regard to the header, it may be that the better approach for Simple would be identify a smaller set of must-haves but permit a larger set of elements for more complex metadata. This may be particularly useful for corpus based projects like DTA or TCP.

From: Martin Holmes <notifications@git.luolix.topmailto:notifications@github.com>
Reply-To: TEIC/TEI-Simple <reply@reply.git.luolix.topmailto:reply@reply.github.com>
Date: Thursday, June 4, 2015 at 7:26 PM
To: TEIC/TEI-Simple <TEI-Simple@noreply.git.luolix.topmailto:TEI-Simple@noreply.github.com>
Subject: Re: [TEI-Simple] Simple schema allows <listPerson> but not <person> (#20)

Also, how about having particDesc as a place to put the listPerson?

Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-109102227.

[martindholmes]

That's similar to my situation: I have a particDesc to deal with, but I ended up putting it in the <back> because it's not a <castList> at all (and people keep reminding me that <castList> is only for encoding real cast lists from the source document, not for anything else).

On the plus side, I'm really fond of the @rendition values, and for @place I found that it was easier to switch our project to using Simple's values in our schema rather than map between them and convert. This is a very positive effect.

[sebastianrahtz]

person element back in....

[martindholmes]

I'm happy to have a usable listPerson, but the question is where it can be used. We surely need a particDesc, don't we? The other option would be to move stuff from particDesc to sourceDesc, which can accommodate a listPerson, but I'm not sure how appropriate that would be.

Given that most Simple documents (initially at least) will be converted from existing TEI documents, I think it would be a good idea to have a recommended strategy for dealing with components like this.

[martinmueller39]

particDesc is only allowed in the teiHeader. It would solve problems that I've run into, and Martin H. and I will probably not be the only ones. We may end up saying that "Simple" is more about TEI/text than TEI/teiHeader, but that's OK. Or so I think.

From: Martin Holmes <notifications@git.luolix.topmailto:notifications@github.com>
Reply-To: TEIC/TEI-Simple <reply@reply.git.luolix.topmailto:reply@reply.github.com>
Date: Monday, June 8, 2015 at 10:15 AM
To: TEIC/TEI-Simple <TEI-Simple@noreply.git.luolix.topmailto:TEI-Simple@noreply.github.com>
Cc: Martin Mueller <martinmueller@northwestern.edumailto:martinmueller@northwestern.edu>
Subject: Re: [TEI-Simple] Simple schema allows <listPerson> but not <person> (#20)

I'm happy to have a usable listPerson, but the question is where it can be used. We surely need a particDesc, don't we? The other option would be to move stuff from particDesc to sourceDesc, which can accommodate a listPerson, but I'm not sure how appropriate that would be.

Given that most Simple documents (initially at least) will be converted from existing TEI documents, I think it would be a good idea to have a recommended strategy for dealing with components like this.

Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-110034514.