[tei-council] addition of <availability>

[Martin Holmes]

On 14-09-09 08:31 AM, Syd Bauman wrote:
> Well, we *have* already discussed it at a face-to-face, but
> apparently we didn't do anywhere near a thorough enough job.
>
> We may be able to take care of this via e-mail, but nonetheless I'm
> in favor of leaving <availability> as a member of model.biblPart but
> backing out the addition of <availability> into the content models of
> <analytic>, <monogr>, and <serial> for this release.

Having re-read the ticket, I'm not sure about that. It would mean that 
<availability> is not available anywhere in <biblStruct>. Council 
already agreed that it should be in <analytic>, <series> and <monogr>. 
Elli decided also to put it in <edition>, but I think we could roll that 
one back on the basis that we haven't had a chance to discuss it, and it 
may not be necessary given the other locations it will be available.

There's no dispute about <analytic> and <series>, so we should implement 
those as we decided. The remaining issue is only about where it should 
go in <monogr>, so I'd suggest deciding right now by email whether it 
should go directly in <monogr> or in <imprint>, as Kevin argues. If we 
can't decide, then we should hold off on the decision about <monogr>, 
but still put it in <analytic> and <series> for now.

Let's have a quick poll, in case it turns out we're all actually in 
agreement anyway:

Kevin says that "Since <publicationStmt> is akin to <imprint> just as 
<editionStmt> is akin to <edition>, I suggest that if we want to support 
use of <availability> inside <monogr>, it should be allowed only as a 
child of <imprint>, which contains information relating to "[. . .] 
distribution of a bibliographic item". Just as bibliographies sometimes 
describe editions and sometimes copies, bibliographic items may be 
editions or copies."

I find that quite convincing, so I vote for <availability> as a child of 
<imprint> and not a direct child of <monogr> (since a <monogr> must 
always have an <imprint>).

What do you all think?

Cheers,
Martin

>
>
>> Anything to do with <biblStruct> is always thorny. But I think one
>> thing we should probably not do is to introduce an element in a new
>> place only to remove it in a subsequent release after more debate.
>> So it might be prudent to remove any remotely controversial changes
>> from this release, and open up the ticket again for us to deal with
>> at the face-to-face.
>>
>> On the other hand, you might just want to allow it everywhere
>> anyone wants it, put that in the release and walk away with relief
>> from a fait accompli. :-)