[tei-council] addition of <availability>

[Mylonas, Elli]

OK, James went with 2 as well, in an earlier email. I feel that the path of
least resistance is to remove the 2nd <availability> from the edition part
of <monogr> and leave things as they are now. which is 1. This allows us to
add it into the <imprint> or <biblStruct>

 --elli

On Tue, Sep 9, 2014 at 2:26 PM, Syd Bauman <
syd at paramedic.wwp.northeastern.edu> wrote:

> With respect to <biblStruct>, <availability> goes inside:
>
>  1. <series>, <analytic>, and <monogr> (as already implemented)
>
>  2. <series> and <analytic>, but as a grandchild of <monogr>
>     inside <imprint>
>
>  3. <biblStruct>
>
>  4. <biblStruct>, <series>, <analytic>, and <monogr>
>
>  5. <biblStruct>, <series>, <analytic>, and <imprint>
>
>  6. not allowed as a descendant of <biblStruct> this release, giving
>     us time to figure out which of the above to do.
>
> If I understand correctly:
>
>  * Kevin and Martin favor #2
>
>  * Fabio and Elli prefer #3, but are OK w/ #1
>
>  * Lou, Syd, Sebastian, James, Hugh, Stefanie, Paul, and Peter have
>    not indicated a preferences yet. HURRY!
>
>
> > The numbers confuse me - are we at the point now where Martin and
> > Kevin are in favor of <availability> as direct child of <series>
> > and <analytic> and grandchild of <monogr> inside <imprint> ?
> >
> > Kevin's switching seems backward, he seems to be asserting that he
> > is switching to what he initially supported,
> >
> > Fabio is in favor of <availability> should be permitted as a direct
> > child of <biblStruct> (presumably along with model.noteLike, idno,
> > model.ptrLike, relatedItem, and citedRange after the ultimate
> > <monogr> or <series>), but not as a descendant of <series>,
> > <monogr>, or <analytic>.
> >
> > I am going along with Fabio,
> --
> 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
>