My first impulse would be to mention both strategies, with a clear preference for the second (as you already said). The simple one could be convenient for cases where no coordinates, surfaces and zones are given and for environments which consider image references in <pb> but not in <facsimile>. -----Ursprüngliche Nachricht----- Von: tei-council-bounces@lists.tei-c.org [mailto:tei-council-bounces@lists.tei-c.org] Im Auftrag von Lou Burnard Gesendet: Samstag, 23. Juli 2016 10:41 An: tei-council@lists.tei-c.org Betreff: Re: [tei-council] Simple : facsimile OK, so while I have your attention, where do we stand on the following issue: At present we mention the fact that you can do a quick and dirty page/image alignment like this <pb facs="page1.png"/> In the section I am currently writing for <facsimile> I naturally want to say that page/image alignment should be done like this: <pb facs="#page1"/> where "page1" identifies a <surface> or <zone>. Should we no longer mention the former strategy? On 23/07/16 10:14, James Cummings wrote:

That is how I would have suggested doing it. So works for me.

James

-- Dr James Cummings, Academic IT Services, University of Oxford

On 23 Jul 2016 09:09, Lou Burnard wrote: Also, having looked more closely, it seems that if you want to encode page openings, you're probably better off encoding the opening as a single surface and each page as zone within it, since you can't define a coordinate system for a pageGrp. So, pending further clarification of this issue, surfaceGrp is OUT.

On 22/07/16 20:48, Lou Burnard wrote:

...

In general, I am all in favour of reducing complexity in Simple, as I hope is by now evident. But I seriously do think we should include surfaceGrp, because the distinction between a single page (a surface) and a page opening (a surfaceGrp containing two surfaces) is a crucial one for many people. But I can survive being outvoted!

On 22/07/16 20:43, Scholger, Martina (martina.scholger@uni-graz.at) wrote:

...

+1

Best, Martina

-----Ursprüngliche Nachricht----- Von: tei-council-bounces@lists.tei-c.org [mailto:tei-council-bounces@lists.tei-c.org] Im Auftrag von James Cummings Gesendet: Donnerstag, 21. Juli 2016 19:35 An: tei-council@lists.tei-c.org Betreff: Re: [tei-council] Simple : facsimile

Sure, I agree. Just suggesting that if you are grouping surfaces and such then you are starting to leave the realm of Simple and should maybe do your own customisation. ;-)

-James

On 21/07/16 18:34, Lou Burnard wrote:

...

Just to repeat, what I said below, surfaceGrp is nothing to do with sourceDoc. It's for grouping surfaces such as page openings, or faces of a monument.

On 21/07/16 19:29, James Cummings wrote:

...

I'm understanding this discussion correctly (and I've just skimmed it in a hurry), then I would be saying that we want facsimile, surface, zone, and graphic, but don't want surfaceGrp, line or sourceDoc.

i.e. we want to be able to do TEI Simple facsimiles as long as they are basic, but not sourceDoc non-interpretative transcriptions. If you need surfaceGrp or sourceDoc, in my mind what you are doing isn't Simple. ;-)

-James

On 21/07/16 17:42, Lou Burnard wrote:

...

On 21/07/16 15:50, Scholger, Martina (martina.scholger@uni-graz.at) wrote: > I think that <surfaceGrp> goes beyond a Simple document, > therefore I would remove it. Well, my reasoning is that whether or not you're doing transcription you will definitely want some way of distinguishing between single page images and images of a page opening, which is precisely ewhat surfaceGrp is for, imho.

> Concerning the <line>: If I understand it correctly, <sourceDoc> > is not provided within a Simple document? Krekt

> Is it meant to have a transcription within <facsimile> instead? > I don't think that <facsimile> should contain a transcription > (see also line 790-793 in tei_simple.odd: "A more powerful > approach, discussed in section <ptr target="#simple-facs"/> > below, is to use the <gi>facsimile</gi> element to define the organization of the > set of images representing the text, and then use > the <att>facs</att> attribute to point to individual components > of that representation.") Agreed, that putting transcription inside <zone> seems a bit (ahem) odd, but you still need to ability to identify zones on an image, whether or not you put text inside them, and the content model for <zone> allows text. Are you are saying that it should actually be forbidden if the ancestor of <zone> is a <facsimile> rather than a <sourceDoc>? > Therefore I wouldn't restore <line>. Understood. > -----Ursprüngliche Nachricht----- > Von: tei-council-bounces@lists.tei-c.org > [mailto:tei-council-bounces@lists.tei-c.org] Im Auftrag von Lou > Burnard > Gesendet: Donnerstag, 21. Juli 2016 13:42 > An: tei-council@lists.tei-c.org; Martin Mueller > Betreff: [tei-council] Simple : facsimile > > The schema currently makes available within <facsimile> : > surface, surfaceGrp, and zone, but not line. > > Is that balance about right? Should I restore <line> (which is > sugar for <zone type="line">) ? Should I remove <surfaceGrp>? > > The purpose is to support a Simple document which contains just > images and the lightest of transcriptions, such as you might get > from a crowd sourcing transcription experiment for example, not > to do full blown genetic transcriptions, obvs. > > > > > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived