_______________________________________________
I think Peter's objection is a killer for putting teiCorpus into model.resourceLike if that is still the case with Syd's formulation of it.
What if instead we simplified the current content model by putting TEI and teiCorpus into a special class all of their own, and then having an alternation between that and model.resourceLike? Or would that result in the same ambiguous situation? I don't have a problem with TEI and teiCorpus being treated the same as long as we don't end up with things like <text> being a child of teiCorpus.
Many thanks,
James
--
Dr James Cummings, James.Cummings@newcastle.ac.uk
Senior Lecturer in Late-Medieval Literature and Digital HumanitiesSchool of English, Newcastle University
From: Tei-council <tei-council-bounces@lists.tei-c.org> on behalf of Peter Stadler <stadler@edirom.de>
Sent: 10 December 2019 07:10
To: Martin Holmes <mholmes@uvic.ca>
Cc: tei-council@lists.tei-c.org <tei-council@lists.tei-c.org>
Subject: Re: [Tei-council] standOff problem #1: content model of <teiCorpus>I’m really sorry not being able to join you later (to bring it forward myself) but please have a look at ticket https://github.com/TEIC/TEI/issues/1823 and PR https://github.com/TEIC/TEI/pull/1922 where I already tried to tackle the content model of teiCorpus. The problem we faced (and still seems evident with Syd’s proposal) that teiCorpus would allow a structure like
<teiCorpus xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>
...
</teiHeader>
<text>
...
</text>
</teiCorpus>
which we thought was not intended.
Best
Peter
> Am 10.12.2019 um 00:50 schrieb Martin Holmes <mholmes@uvic.ca>:
>
> I agree with Syd on this: teiCorpus should be a member of model.resourceLike. The fact that as a result TEI and teiCorpus become essentially the same thing is actually a plus for me. I think any line drawn between the two is terminological rather than structural, and while it might be clearly delineated in the case of particular projects, in the broader view it's very fuzzy indeed.
>
> Cheers,
> Martin
>
> On 2019-12-09 3:16 p.m., Syd Bauman wrote:
>> The current content model of <teiCorpus> is:
>> teiHeader,
>> (
>> ( model.resourceLike+, ( TEI | teiCorpus )* )
>> |
>> ( TEI | teiCorpus )+ )
>> )
>> That is, you may *either* have a series of 1 or more <TEI> and
>> <teiCorpus> elements, intermingled; OR you can have one or more
>> of <facsimile>, <fsdDecl>, <sourceDoc>, and <text> elements
>> intermingled followed by zero or more <TEI> and <teiCorpus> elements
>> intermingled. This is exactly the same as saying
>> teiHeader, model.resourceLike*, ( TEI | teiCorpus )*
>> except that it requires at least one child <TEI>, <teiCorpus>,
>> <facsimile>, <fsdDecl>, <sourceDoc>, or <text>.
>> In the new <standOff> world, we have voted to make <TEI> a member of
>> model.resourceLike. Thus we have to alter the content model of
>> <teiCorpus> because as written it would be ambiguous (if a <TEI> is
>> your first child after <teiHeader>, you don't know which branch of
>> the content model you are in).
>> It is not too difficult to solve the ambiguity problem:
>> teiHeader,
>> (
>> ( model.resourceLike+, ( teiCorpus, ( TEI | teiCorpus )* )? )
>> |
>> ( teiCorpus, ( TEI | teiCorpus )* ) )
>> )
>> I am pretty confident this content model validates the same set of
>> documents (and, perhaps as importantly, rejects the same set of
>> documents) as the original content model (with <TEI> in
>> model.resourceLike). I am not against using this content model. But
>> it occurs to me that
>> a) it is a bit cumbersome
>> b) the set of documents permitted is already screwy
>> c) it looks very different from the content model of <TEI>, which
>> (in the new world order) <teiCorpus> is very similar to.
>> One possible solution is to
>> 1) add <teiCorpus> to model.resourceLike, too; and then
>> 2) change content model of <teiCorpus> to match that of <TEI> (in
>> the new standOff world):
>> teiHeader, model.resourceLike+
>> This has the advantage of having a very clean, understandable content
>> model for <teiCorpus> (and no ambiguity). It has the disadvantage
>> that it allows for even more screwy things. E.g.
>> <teiCorpus>
>> <teiHeader>
>> <standOff>
>> <TEI>
>> <facsimile>
>> <TEI>
>> <teiCorpus>
>> <TEI>
>> <facsimile>
>> <TEI>
>> <teiCorpus>
>> <facsimile>
>> </teiCorpus>
>> It has the feature (which some will consider an advantage, others a
>> disadvantage, I'm sure) that <TEI> and <teiCorpus> become the same
>> thing. Just as an XSLT stylesheet can have an outermost element of
>> <xsl:stylesheet> or <xsl:transform>, no difference, a TEI document
>> will be able to have <TEI> or <teiCorpus> as an outermost element, no
>> difference. Same goes at every level of nesting where one is allowed:
>> so is the other, and it can have the same content.
>> Personally, I still think putting <TEI> into model.resourceLike was
>> probably a mistake, but once we've done that, I'm inclined to say
>> throw <teiCorpus> in there, too.
>> _______________________________________________
>> Tei-council mailing list
>> Tei-council@lists.tei-c.org
>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
>
> --
> ------------------------------------------
> Martin Holmes
> UVic Humanities Computing and Media Centre
> _______________________________________________
> Tei-council mailing list
> Tei-council@lists.tei-c.org
> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council