[tei-council] addition of <availability>

[Fabio Ciotti]

Kosher enough. In general I would avoid the dispersion of an element
in so many different contexts (especially a metadata element) if there
are reasonable and more general solutions to cope with the
requirements

f

2014-09-09 17:37 GMT+02:00 Mylonas, Elli <elli_mylonas at brown.edu>:
> I think it definitely belongs in <biblPart>, but am willing to remove from
> <analytic>, <serial> and definitely <monogr>
>
> will do that during the day today. Is that kosher? --elli
>
> On Tue, Sep 9, 2014 at 11:31 AM, Syd Bauman <
> syd at paramedic.wwp.northeastern.edu> 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.
>>
>>
>> > 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. :-)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived