-
Notifications
You must be signed in to change notification settings - Fork 9
/
elife-00666.xml
4548 lines (4521 loc) · 264 KB
/
elife-00666.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!--
to avoid conflict with article 00666,
kitchen sink has been copied to: ./elife-1234567890-v1/elife-1234567890-v1.xml
please use that.
-->
<!-- UPDATE: eLife is updating to the most recent version of JATS, 1.2 --><!--we use subj-groups to indicate eLife-specific terms. The @article-type on article drives the template used on the html version of the article and is also used for PubMed deposits.
The @article-types currently used are:
article-commentary - Insight (Feature template 1)
correction - Correction
retraction - Retraction
discussion - Feature contribution (Feature template 3 or 4)
editorial - Editorial (Feature template 2)
research-article - all research content and feature research articles (Feature template 5)
review-article - Review articles
UPDATE: xmlns:ali="http://www.niso.org/schemas/ali/1.0/" this name space is added in order to add the new license information (see permissions section)
-->
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN" "JATS-archivearticle1.dtd">
<article xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article" dtd-version="1.2">
<front>
<!-- journal-meta is standard for all articles published by eLife. Can be boilerplate text as this will not change from article to article.
UPDATE: <journal-id journal-id-type="hwp">eLife</journal-id> has been removed - we are no longer hosted by HighWirePress so this is not required -->
<journal-meta>
<journal-id journal-id-type="nlm-ta">elife</journal-id>
<journal-id journal-id-type="publisher-id">eLife</journal-id>
<journal-title-group>
<journal-title>eLife</journal-title>
</journal-title-group>
<issn publication-format="electronic" pub-type="epub">2050-084X</issn>
<publisher>
<publisher-name>eLife Sciences Publications, Ltd</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<!-- @pub-id-type publisher-id - this is always a 5 digit number -->
<article-id pub-id-type="publisher-id">00666</article-id>
<!-- @pub-id-type doi - always has eLife prefix (10.7554/eLife.) followed by same 5 digit number as publisher id -->
<!--UPDATE: PDF links to DOIs: from CrossRef: The updated Crossref DOI Display guidelines recommend that https://doi.org/ be used and not http://dx.doi.org/ in DOI links.
Originally the “dx” separated the DOI resolver from the International DOI Foundation (IDF) website but this has changed and the IDF has already updated its recommendations
so we are bringing ours in line with theirs. We are also recommending the use of HTTPS because it makes for more secure browsing.
-->
<!-- UPDATE: DOI prefix removed from XML but must be added to display in PDF and HTML-->
<article-id pub-id-type="doi">10.7554/eLife.00666</article-id>
<article-categories>
<!-- @subj-group-type "display-channel" - eLife-defined article type, controlled list for Research Content (case sensitive):
Research Article
Short Report
Tools and Resources
Research Advance - this article type MUST have related article tagging with an @related-article-type of "article-reference" and an xlink:href to the doi of the related article (e.g."10.7554/eLife.00109")
Registered Report - there will be a different kitchen sink for this article type to indicate how to link to the paper it is being built upon
Replication Study - there will be a different kitchen sink for this article type to indicate how to link to the paper it is being built upon -->
<subj-group subj-group-type="display-channel">
<subject>Research Article</subject>
</subj-group>
<!-- @subj-group-type heading - eLife-defined major subject area. By default, there are up to 2 per article; however more can be added at author
request. This is a controlled list (case sensitive):
Biochemistry
Biophysics and Structural Biology
Cell Biology
Computational and Systems Biology
Developmental Biology and Stem Cells
Ecology
Epidemiology and Global Health
Genes and Chromosomes
Genomics and Evolutionary Biology
Human Biology and Medicine
Immunology
Microbiology and Infectious Disease
Neuroscience
Plant Biology -->
<subj-group subj-group-type="heading">
<subject>Cell Biology</subject>
</subj-group>
<subj-group subj-group-type="heading">
<subject>Plant Biology</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>The eLife research article</article-title>
</title-group>
<contrib-group>
<!-- Each contrib MUST have following attributes:
1) @contrib-type - "author".
2) id="author-XXXXX" - this is the unique number assigned to an author via the submission system (this is output in the XML from the submission system.
The contrib MAY have following attributes:
1) equal-contrib="yes" - can only be used if an author contributed equally with another author and this attribute must be present on both their contribs.
There is no limit on the number authors who can have equal contributions and there can be separate groups of equal contribution.
This is linked to a footnote via an xref.
UPDATE: The rid should be equal-contrib1, equal-contrib2 etc to indicate which equal contrib group each author is part of. Even if there is only one
group, the number suffix is still required.
2) deceased="yes" - only used if author is now dead.
3) corresp="yes" - only used if the author is a corresponding author. There can be more than one corresponding author and there is no limit to the number
of corresponding authors. A corresponding author must have an email address contained within their contrib.
PDF display: Corresponding author footnote on PDF always takes symbol *(*).
Footnotes to affiliations follow the superscript numbering system (1,2,3 etc).
All succeeding footnotes use the following symbols in order: † (†), ‡ (‡), § (§), # (#), ¶ (¶),**,††, ‡‡,§§,## ,¶¶ -->
<contrib contrib-type="author" corresp="yes" equal-contrib="yes" deceased="yes">
<name>
<surname>Harrison</surname>
<given-names>Melissa</given-names>
<suffix>Jnr</suffix>
</name>
<!-- Corresponding author (correspondent for peer review process) must have an ORCID; all other authors are encouraged but not required to have one.
NOTE: There can be multiple corresponding authors and they may not all have an ORCID as only one will be the primary correspondent for peer review. The
primary corresponding author will be indicated as the corresponding author for the proofing process in the output XML from the submission system, but
this distinction will not be retained in the final XML. -->
<contrib-id contrib-id-type="orcid" authenticated="true">https://orcid.org/0000-0003-3523-4408</contrib-id>
<!-- UPDATE: email for corresponding author is contained within contrib and no longer in author notes.
For PDF display footnote "*For correspondence: " must be added as boilerplate followed by the email address pulled in from the XML.If there are multiple
corresponding authors, the email addresses must be added in order of the author list, separated with semicolons. Author initials should to be added in
brackets after each email address. See Kitchen sink PDF for example.-->
<email>m.harrison@elifesciences.org</email>
<!-- xref links within contrib should be in the following order, which also reflects the order of the footnote symbols:
presence of an email address indicates for correspondence *
Affiliations - take numbered footnotes
Following are optional but in this order:
Equal contributions - first set, second set etc
Present address - 1st, 2nd, etcevent
Deceased
Other footnotes-->
<!-- Author affiliation(s) are linked to a contrib via the xref link to their "aff". Each affiliation has a unique id, aff1, aff2, aff3 etc, which corresponds
to the number used in the label
Authors can have one or multiple affiliations. There should be one aff per unique affiliation and these are shared between authors, not repeated.
xref link requires display number (e.g. see below "1"). This is required for PMC and PDF build-->
<xref ref-type="aff" rid="aff1">1</xref>
<!-- Equal contributions are linked to a contrib via the footnote with attribute fn-type="fn" and the corresponding id (equal-contrib1, equal-contrib2 etc).-->
<xref ref-type="fn" rid="equal-contrib1">†</xref>
<!-- Present addresses are linked to a contrib via the footnote with attribute fn-type="present-address" and the corresponding id (pa1, pa2 etc). There is no limit
on the number of present addresses allowed per author and multiple authors can share a single present address.-->
<xref ref-type="fn" rid="pa1">§</xref>
<!-- Other footnotes are linked to a contrib via the footnote with attribute fn-type="fn" and the corresponding id (fn1, fn2 etc). No limit on the number allowed
per author and multiple authors can share the same footnote. There is no display text associated with this link.
Other footnotes are rare (they have only been used 3 times in the history of eLife) -->
<xref ref-type="fn" rid="fn1">#</xref>
<xref ref-type="fn" rid="fn2">¶</xref>
<!-- Authors who have funding declared on the article are linked to the relevant <award-group> via an xref link using the"fund" id. Each <award-group> id
should have a unique number e.g. fund1, fund2 etc. Authors can have one or multiple award-groups and multiple authors can be associated with one
award-group. There is no display text associated with this link
UPDATE: ID value changed from par to fund and hyphen removed to be consistent with other IDs. All ids have a number value suffix even if only 1 exist in the article, e.g. fund1, fund2. -->
<xref ref-type="other" rid="fund1"/>
<!-- Author competing interests statement is linked to a contrib via the footnote with attribute fn-type="conflict" and the corresponding id (conf1, conf2 etc).
Only one is allowed per author. If the author has no competing interest, this footnote can be shared with other authors.
Where a competing interest is listed, this must be unique to the author. There is no display text associated with this link within contrib -->
<xref ref-type="fn" rid="conf1"/>
<!-- Author contributions are linked to a contrib via the footnote with attribute fn-type="con" and the corresponding id (con1, con2 etc). Only one is allowed per
author. There is no display text associated with this link-->
<xref ref-type="fn" rid="con1"/>
<!-- Datasets are linked to a contrib using an xref with type "other" and the unique id for the dataset (dataset1, dataset2 etc).
UPDATE: ID value changed from dataro to dataset. All ids have a number value even if only 1 exist in the article. -->
</contrib>
<contrib contrib-type="author" equal-contrib="yes">
<name>
<surname>Gilbert</surname>
<given-names>James F</given-names>
</name>
<xref ref-type="aff" rid="aff1">1</xref>
<xref ref-type="fn" rid="equal-contrib1">†</xref>
<xref ref-type="fn" rid="conf2"/>
<xref ref-type="fn" rid="con2"/>
</contrib>
<!-- UPDATE: group authors. If the individuals of the group are listed, they now will be listed as a contrib-group and contributors within collab.
They are no longer separated from their group name in tagging and linked by author key. Multiple group authors are allowed and their position in the author
list displayed in the PDF is retained as per the XML order-->
<contrib contrib-type="author" equal-contrib="yes">
<collab>eLife Editorial Production Group
<contrib-group>
<!-- UPDATE: use of role in group authors. If a group author is subdivided into sections or sub-groups, this is indicated using the role tag-->
<role>Writing group</role>
<contrib>
<name>
<surname>Shearer</surname>
<given-names>Alistair</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Caton</surname>
<given-names>Hannah</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
<aff>
<institution>eLife Institute</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
</contrib-group>
<contrib-group>
<role>Editing group</role>
<contrib>
<name>
<surname>Chan</surname>
<given-names>Wei Mun</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Drury</surname>
<given-names>Hannah</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Guerreiro</surname>
<given-names>Maria</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Richmond</surname>
<given-names>Susanna</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
</contrib-group>
</collab>
<xref ref-type="aff" rid="aff1">1</xref>
<xref ref-type="fn" rid="equal-contrib2">‡</xref>
<xref ref-type="fn" rid="con3"/>
<xref ref-type="fn" rid="conf2"/>
</contrib>
<contrib contrib-type="author" equal-contrib="yes" corresp="yes">
<collab>eLife Technology Group
<contrib-group>
<!-- UPDATE: A group author member can have an affiliation, but it is contained within the contrib after their name rather than listed separately. Group author
affiliations are truncated compared to normal author affiliations (usually just institution, city and country) -->
<!-- A group author member can have an ORCID, although this is not required -->
<contrib>
<name>
<surname>Nott</surname>
<given-names>Graham</given-names>
</name>
<aff>
<institution>Graham Nott Enterprises</institution>
<addr-line>
<named-content content-type="city">Victoria</named-content>
</addr-line>
<country>Canada</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Wilkinson</surname>
<given-names>Chris</given-names>
</name>
<email>c.wilkinson@elifesciences.org</email>
<contrib-id contrib-id-type="orcid" authenticated="true">https://orcid.org/0000-0003-4921-6155</contrib-id>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib>
<name>
<surname>Skibinski</surname>
<given-names>Luke</given-names>
</name>
<aff>
<institution>eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
</contrib>
</contrib-group>
</collab>
<email>blah@blah.com</email>
<xref ref-type="aff" rid="aff2">2</xref>
<xref ref-type="fn" rid="equal-contrib2">‡</xref>
<xref ref-type="other" rid="fund2"/>
<xref ref-type="fn" rid="conf3"/>
<xref ref-type="fn" rid="con4"/>
</contrib>
<!-- 'on behalf of' can be used in any position of the author list. It must be retained in the correct position in the author list.
Most of the time it is the last entry, but this is not a requirement.
Note: if the display requires on behalf of, this is required in the textaul entry. This is because it might be "for" instead of "on-behalf of" and the html display
cannot make that distinction by reading the textual entry-->
<on-behalf-of>for the eLife Staff Team</on-behalf-of>
<!-- Affiliations are granular and a department field must contain only one department. For example, two departments at one institution (see below) generate two
separate affiliations
UPDATE: Punctuation outside of XML tags has been removed as it is not necessary. Commas between department, institution, city and country will
need to be boilerplate for the PDF display-->
<aff id="aff1">
<label>1</label>
<institution>Department of Production, eLife</institution>
<addr-line>
<named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
<aff id="aff2">
<label>2</label>
<institution>Department of Technology, eLife</institution>
<addr-line><named-content content-type="city">Cambridge</named-content>
</addr-line>
<country>United Kingdom</country>
</aff>
<!-- eLife articles are shepherded through the review process by a reviewing editor, who is listed in the XML and called out in the online and PDF displays.
UPDATE: As above, punctuation outside XML tags has been removed -->
</contrib-group>
<contrib-group content-type="section">
<contrib contrib-type="senior_editor">
<name>
<surname>Harrison</surname>
<given-names>Melissa</given-names>
</name>
<role>Senior Editor</role>
<aff>
<institution>eLife</institution>
<country>United Kingdom</country>
</aff>
</contrib>
<contrib contrib-type="editor">
<name>
<surname>Collings</surname>
<given-names>Andy</given-names>
</name>
<role>Reviewing Editor</role>
<aff>
<institution>eLife Sciences</institution>
<country>United Kingdom</country>
</aff>
</contrib>
</contrib-group>
<author-notes>
<!-- UPDATE: Correspondence - removed from author-notes
For PDF display footnote "*For correspondence: " must be added as boilerplate followed by the email address pulled in from the XML.If there are multiple
corresponding authors, the email addresses must be added in order of the author list, separated with semicolons. Author initials should to be added in
brackets after each email address. See Kitchen sink PDF for example.
UPDATE: email for corresponding author is contained within contrib and no longer in author notes.
-->
<!--Equal contributions footnote-->
<fn fn-type="con" id="equal-contrib1">
<label>†</label>
<p>These authors contributed equally to this work</p>
</fn>
<fn fn-type="con" id="equal-contrib2">
<label>‡</label>
<p>These authors also contributed equally to this work</p>
</fn>
<!--Present address s footnote-->
<fn fn-type="present-address" id="pa1">
<label>§</label>
<p>Department of Wellcome Trust, Sanger Institute, London, United Kingdom</p>
</fn>
<!-- Other footnotes Deceased
Other footnotes are rare (they have only been used 3 times in the history of eLife. The text of the footnote is transitioned directly to the website, so the
content must work as a discrete item on each author's roll over and on the display at the end of the article -->
<fn fn-type="fn" id="fn1">
<label>#</label>
<p>Deceased (not really!!)</p>
</fn>
<fn fn-type="fn" id="fn2">
<label>¶</label>
<p>This footnote text must work in isolation as nothing is processed on the html view to make it "work"</p>
</fn>
</author-notes>
<pub-date publication-format="electronic" date-type="publication">
<day>25</day>
<month>04</month>
<year>2016</year>
</pub-date>
<!-- CHANGE: pub-date will still continue to keep the first (whether PoA or VoR) pub date in the XML with a date-type="publication".
This date will remain in all instances of the XML for an article. If a further version is published another date wil be added, with a
date-type="update". Each time a new instance of the XML is published, the pub date with the date-type="update" will be replaced with the new date of
the publication date of this instance. There will only ever be two pub dates in an XML file.
<pub-date publication-format="electronic" date-type="update">
<day>11</day>
<month>08</month>
<year>2016</year>
</pub-date>
<pub-date publication-format="electronic" date-type="publication">
<day>25</day>
<month>04</month>
<year>2016</year>
</pub-date>
-->
<!-- TO NOTE: pub-type collection required for Continuum to process content as VoR. Also required for PMC-->
<pub-date pub-type="collection">
<year>2016</year>
</pub-date>
<volume>5</volume>
<elocation-id>e00666</elocation-id>
<history>
<date date-type="received" iso-8601-date="2016-03-01">
<day>01</day>
<month>03</month>
<year>2016</year>
</date>
<date date-type="accepted" iso-8601-date="2016-04-01">
<day>01</day>
<month>04</month>
<year>2016</year>
</date>
</history>
<!-- events added to pub-history.
Pending JATS4R rec has this in <history> but that is not currently allowed in JATS 1.2.
In the event of a new version, the first (or more) VoR publication dates would move down here as an event
and the new version publicaiton date would replace pub-date[@date-type="update"] above.
VoR dates in the <event> would have a self-uri[@content-type="version-of-record"].
Any new version pub dates moved to event (for example if there were 2+ new versions) would have a
self-uri[@content-type="corrected-version-of-record"].
-->
<pub-history>
<!-- events added in chronological order -->
<event>
<event-desc>This manuscript was published as a preprint at bioRxiv.</event-desc>
<date date-type="preprint" iso-8601-date="2016-02-01">
<day>01</day>
<month>02</month>
<year>2016</year>
</date>
<!-- "preprint" or "pre-print"? Examples and text in JATS4R conflict:
https://jats4r.org/article-publication-and-history-dates/#example-2
https://jats4r.org/article-publication-and-history-dates/#comment-308 -->
<self-uri content-type="preprint" xlink:href="http://doi.org/10.5555/12345678"/>
</event>
</pub-history>
<!-- UPDATE: Permissions: this has changed/been updated to include the free_to_reed tag further to NISO recommendations -->
<permissions>
<copyright-statement>© 2016, Harrison et al</copyright-statement>
<copyright-year>2016</copyright-year>
<copyright-holder>Harrison et al</copyright-holder>
<ali:free_to_read/>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/">
<ali:license_ref>http://creativecommons.org/licenses/by/4.0/</ali:license_ref>
<license-p>This article is distributed under the terms of the <ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/4.0/">Creative
Commons Attribution License</ext-link>, which permits unrestricted use
and redistribution provided that the original author and source are
credited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="elife-00666.pdf"/>
<!-- Some content will not have a figures PDF -->
<self-uri content-type="figures-pdf" xlink:href="elife-00666-figures.pdf"/>
<!-- UPDATE: Abstract: The following is no longer required for the XML file. However, it must be displayed in the PDF:
<bold>DOI:</bold>
<ext-link ext-link-type="doi" xlink:href="10.7554/eLife.00666.001">https://doi.org/10.7554/eLife.00666.001</ext-link> -->
<abstract>
<p>This is the abstract. This article will describe the eLife article and the process.
An abstract can contain any formatting, such as <italic>italics</italic>,
<bold>bold</bold>, <sup>superscript</sup>, <sub>subscript</sub> or <sc>small caps</sc>. MathML is
also allowed:
<inline-formula><mml:math id="inf1">
<mml:mrow>
<mml:munder>
<mml:mo/>
<mml:mi>m</mml:mi>
</mml:munder>
<mml:mrow>
<mml:msub>
<mml:mover accent="true">
<mml:mi>p</mml:mi>
<mml:mo/>
</mml:mover>
<mml:mi>m</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
.</p>
<p>eLife does not structure abstracts into sub headings expect in a clinical trial article, but the abstract can have
multiple paragarahs. The sub DOI is always .001 as it is the first asset in any
article. I have added an unmatched > bracket as this has been an issue for PubMed deposits in the past.</p>
<p>If this was a clinical trial the clinical trial details would be listed at the end of the abstract:</p>
<p>Clinical trial Registration: EudraCT2004-000446-20.</p>
</abstract>
<!-- UPDATE: Abstract: The following is no longer required for the XML file. However, it must be displayed in the PDF and the display must include prefix https://doi.org/
<bold>DOI:</bold>
<ext-link ext-link-type="doi" xlink:href="10.7554/eLife.00666.001">https://doi.org/10.7554/eLife.00666.002</ext-link>
Additionally, digest are no longer a required component of all Research Articles and Short Reports. All research content can now be published with no digest -->
<abstract abstract-type="executive-summary">
<title>eLife digest</title>
<p>eLife digest are now optional and not every research article will contain one.
These are layman abstracts, designed for non-specialists in this field to be
able to understand this article, as well as the general public.</p>
<p>Here is paragraph 2 of the digest.</p>
</abstract>
<!-- UDPATE: Author keywords: removed title from XML - is implicit in the @kwd-group-type
Can contain italics, but no bold or other formatting-->
<kwd-group kwd-group-type="author-keywords">
<kwd>XML</kwd>
<kwd>Housestyle</kwd>
<kwd>eLife</kwd>
<kwd>
<italic>formatting</italic>
</kwd>
</kwd-group>
<!-- Output what is provided during the production process-->
<kwd-group kwd-group-type="research-organism">
<title>Research organism</title>
<kwd>Human</kwd>
<kwd>Machine</kwd>
</kwd-group>
<!-- Funding: The website will match any author ID contrib which is xref linked to this section and will ignore the name pulled in. However, production want to
leave the name in the XML as we feel it is better for TDM. We can add Schematron validation to ensure the name listed here matches the name listed with the ID.
There is no limit to the number of award groups or on the number of authors assigned to each award group.
Rules:
One award-group per each unique award-id, although award-id is not required for each award-group.
Minimum of one author per funding source. Maximum is the number of authors on the article.
Individual members of a group authorship should not be named in the funding section, only the group author itself as it appears in the main author list
UPDATE: if there is no Fundref ID then the @institution-id-type="FundRef" should not be present-->
<funding-group>
<award-group id="fund1">
<funding-source>
<institution-wrap><institution-id institution-id-type="FundRef">https://dx.doi.org/10.13039/100000011</institution-id>
<institution>Howard Hughes Medical Institute</institution>
</institution-wrap>
</funding-source>
<award-id>F32 GM089018</award-id>
<principal-award-recipient>
<name>
<surname>Harrison</surname>
<given-names>Melissa</given-names>
</name>
</principal-award-recipient>
</award-group>
<!-- UPDATE: if an award recipient is a group, cannot use collab or name without subdivision, so added string-name-->
<award-group id="fund2">
<funding-source>
<institution-wrap>
<institution>Laura and John Arnold Foundation</institution>
</institution-wrap>
</funding-source>
<principal-award-recipient>
<string-name>eLife Technology Group</string-name>
</principal-award-recipient>
</award-group>
<funding-statement>The funders had no role in study design, data collection and interpretation, or the decision to submit the work for publication.</funding-statement>
</funding-group>
<!-- UPDATE: Custom-meta: no longer using eLife version as was never used properly.
Impact statement:-->
<custom-meta-group>
<custom-meta specific-use="meta-only">
<meta-name>Author impact statement</meta-name>
<meta-value>How to tag an eLife article using JATS XML.</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body>
<!--
The headings used by eLife are standardised at the top level and sec is used, with a sec-type.
An A heading can be identified by the ID not having a further subdivision, for example S1 is the first section heading.
If there are B headings in this section they will have a sec id of S1-1 etc
eLife allowed A heads for research content are:
Introduction - sec-type="intro"
Results - sec-type="results"
Discussion - sec-type="discussion"
Materials and methods - sec-type="materials|methods"
Exceptions:
A merged results and discussion section is acceptable:
Results and discussion - sec-type="results|discussion"
Discussion - sec-type="discussion"
For Methods articles - identifiable as articles that describe models and are generally maths-heavy - the following structure is allowed:
Introduction sec-type="intro"
Model - sec-type="model"
Results - sec-type="results"
Discussion - sec-type="discussion"
OR
Introduction sec-type="intro"
Methods - sec-type="methods"
Results - sec-type="results"
Discussion - sec-type="discussion"
For research advances: Authors have more flexibility with structure and sections can be combined, although the Materials and methods section
is mandatory.
To allow for the flexibility, a title is also appeneded to each section
-->
<sec sec-type="intro" id="s1">
<title>Introduction (Level 1 heading)</title>
<p>This article is a guide to the tagging and display of eLife articles and will
encompass all the elements that can possibly be contained in an eLife article.
It will also include information from the author guide. For this reason, it is colloquially known as the eLife 'kitchen sink'.</p>
<sec id="s1-1">
<title>The eLife editorial process (level 2 heading)</title>
<p>eLife publishes the most highly influential research across the life sciences and biomedicine.
Before you submit your work, please note that eLife is a very selective journal that aims to publish
work of the highest scientific standards and importance. Leading academic
researchers evaluate new submissions and approximately two-thirds are returned to
the authors without further peer review. See <xref ref-type="bibr" rid="bib12">DeLano (2002)</xref> and <xref ref-type="bibr" rid="bib13">Department of Education and Morgan (2016)</xref>. Approximately half of the articles that are
selected for peer review go on to be published (<xref ref-type="bibr" rid="bib5">Brettar et al., 2004a</xref>). If other researchers publish similar
findings after submission, this will not be a reason for rejection. The eLife
editorial process broadly occurs in three phases (<xref ref-type="bibr" rid="bib47">Turlings and Wäckers, 2004a</xref>; <xref ref-type="bibr" rid="bib48">Turlings and Wäckers, 2004b</xref>; <xref ref-type="bibr" rid="bib50">Wolski et al., 2008</xref>; <xref ref-type="bibr" rid="bib49">Walker, 1994</xref>; <xref ref-type="bibr" rid="bib43">Tanaka et al., 2016</xref>). If you are interested in
submitting your work to eLife, please review the guidelines relating to initial
submissions. If you have received an encouraging response to your initial
submission, please review the guidelines relating to full submissions. If your full
submission has been peer reviewed and you have been asked to make revisions, please
review our guidelines for revised submissions (<xref ref-type="bibr" rid="bib6">Brettar et al., 2004b</xref>).</p>
<sec id="s1-1-1">
<title>Initial submission (level 3 heading)</title>
<p>eLife publishes research of the very highest (<xref ref-type="bibr" rid="bib7">Bricogne et al., 2011</xref>) standard and significance,
so many manuscripts are returned to the authors without in-depth peer review. During the initial submission
phase, members of eLife’s senior editorial team rapidly assess new submissions,
often in consultation with members of the Board of Reviewing Editors or with
external guest editors where necessary, to identify the ones that are appropriate
for in-depth peer review (<xref ref-type="bibr" rid="bib8">Cardé and Millar, 2004</xref>; <xref ref-type="bibr" rid="bib9">Cartwright, 2016</xref>;
<xref ref-type="bibr" rid="bib10">Chmeil, 2008</xref>). To simplify the submission process, authors should submit
their full manuscript as a single PDF. Limited additional information is collected
via the submission screen questions to complete the submission (<xref ref-type="bibr" rid="bib6">Brettar et al., 2004b</xref>).</p>
</sec>
<sec id="s1-1-2">
<title>Full submission (level 3 heading)</title>
<p>For manuscripts that are invited for in-depth peer review, see <xref ref-type="bibr" rid="bib11">Coyne and Orr (1989)</xref>
and <xref ref-type="bibr" rid="bib14">Du et al. (2014)</xref>, we request detailed
information about the work to support the peer review process, to ensure that the
work meets appropriate standards for the reporting of new findings, and, if
accepted, to assist in rapid publication and further dissemination of the work in
relevant indexes and repositories. Authors are asked to agree to publish their work
under the terms of the Creative Commons Attribution license (PDF of the agreement),
or the Creative Commons CC0 public domain dedication (PDF of the agreement) if one
or more authors are US-government employees (<xref ref-type="bibr" rid="bib23">Hubbard and Thornton, 1993</xref>;
<xref ref-type="bibr" rid="bib19">GlaxoSmithKline UK, 2016</xref>; <xref ref-type="bibr" rid="bib24">Jain et al., 2010</xref>).</p>
</sec>
<sec id="s1-1-3">
<title>Revised submission (level 3 heading)</title>
<p>We will require a response to the essential revision requirements outlined in the decision letter. A
response to minor comments is optional. In the event of acceptance, the substantive
revision requests and the authors’ response will be published, under the terms of
the Creative Commons Attribution license. In preparation for submission, authors
should ensure they have all the materials and information necessary to expedite the
submission and assessment of their work (<xref ref-type="bibr" rid="bib15">Eisen, 2016</xref>;
<xref ref-type="bibr" rid="bib16">Ferry et al., 2014</xref>; <xref ref-type="bibr" rid="bib18">Gavrilov et al., 2014</xref>;
<xref ref-type="bibr" rid="bib20">Goodstadt, 2010</xref>; <xref ref-type="bibr" rid="bib21">Hoang et al., 2015</xref>).</p>
</sec>
</sec>
<sec id="s1-2">
<title>The eLife production process (level 2 heading)</title>
<sec id="s1-2-1">
<title>Immediate publication (accepted manuscript) (level 3 heading)</title>
<p>On acceptance an eLife article can be published in accepted manuscript form immediately.
The mean time from acceptance to publication at this stage is 1 day. Using SQl, basic metadata is exported from the submission system to an
AWS bucket as CSV files. The author files are exported to another AWS bucket and an eLife process generates a package of this information and the
author files to deliver to the online platform, Continuum.</p>
</sec>
<sec id="s1-2-2">
<title>Publication of the full version (version of record) (level 3 heading)</title>
<p>The production process includes an author proofing cycle, the output of which is the final full text version of the article online, as well as a typeset PDF.</p>
</sec>
<sec id="s1-2-3">
<title>Publication of versions (level 3 heading)</title>
<p>eLife allows the publication of updates to an article after the full version has been produced. These are treated as new versions of the article. All previous
versions of the article will continue to exist online and will be accessible from the latest live version.</p>
<sec id="s1-2-3-1">
<title>level 4 heading</title>
<p>eLife allows up to four levels of headings and no more. This is a demonstration of a level 4 heading.</p>
</sec>
</sec>
</sec>
</sec>
<sec sec-type="results" id="s2">
<title>Results</title>
<!-- UPDATE: where appendices are cited in the main text they must be cross linked -->
<p>This section will be used to demostrate the majority of eLife XML tagging and editorial policies. However, the Introduction section was used to demostrate heading levels.
See Appendix 1.1 and 2.</p>
<sec id="s2-1">
<title>eLife controlled lists</title>
<p>eLife has no strict requirements for the display of lists. Below we will show examples of how to present lists.
See <xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1</xref> for the representation of the Major Subject Areas, Research
Organisms and author keywords on the eLife HTML page (<xref ref-type="bibr" rid="bib44">The <italic>Shigella</italic> Genome Sequencing Consortium, 2015a</xref>).
</p>
<sec id="s2-1-1">
<title>Article types</title>
<p>This is an example of a list where the prefix character is a lowercase roman numeral. eLife Article Types are taken from a controlled list:</p>
<list list-type="roman-lower">
<list-item><p>Research article</p></list-item>
<list-item><p>Short Report</p></list-item>
<list-item><p>Tools and Resources</p></list-item>
<list-item><p>Research Advance</p></list-item>
<list-item><p>Registered Report</p></list-item>
<list-item><p>Replication Study</p></list-item>
</list>
<sec id="s2-1-1-1">
<title>Article types (XML only, not display) (level 4 heading)</title>
<p>This is an example of a list where the prefix character is a uppercase roman numeral. This is a controlled list from the JATS DTD</p>
<list list-type="roman-upper">
<list-item><p>article-commentary (used for Insights)</p></list-item>
<list-item><p>correction</p></list-item>
<list-item><p>discussion (used for Feature 1 and Feature 2)</p></list-item>
<list-item><p>editorial</p></list-item>
<list-item><p>research-article (all reseasrch content)</p></list-item>
</list>
<p>Nested lists are allowed and these are very common in Registered Peports. Below is an example of a nested list to 3 levels.</p>
<p>Genus: Plasmodium; following species are known to infect humans</p>
<list list-type="roman-upper">
<list-item>
<list list-type="roman-lower">
<list-item>
<p><italic>P. falciparum</italic></p>
</list-item>
<list-item>
<p><italic>P. vivax</italic></p>
</list-item>
<list-item>
<p><italic>P. ovale</italic></p>
</list-item>
<list-item>
<p><italic>P. malariae</italic></p>
</list-item>
<list-item>
<p><italic>P. knowlesi</italic></p>
</list-item>
</list>
<p>Genus: Leishmania. There are 3 subgenus of Leishmania:</p>
</list-item>
<list-item>
<list list-type="roman-lower">
<list-item>
<p>Leishmania</p>
</list-item>
<list-item>
<p>Sauroleishmania</p>
</list-item>
<list-item>
<p>Viannia</p>
</list-item>
<list-item>
<p>Within Viannia subgenus, there are 11 species:</p>
<list list-type="bullet">
<list-item>
<p><italic>L. braziliensis</italic></p>
</list-item>
<list-item>
<p><italic>L. colombiensis</italic></p>
</list-item>
<list-item>
<p><italic>L. equatorensis</italic></p>
</list-item>
<list-item>
<p><italic>L. guyanensis</italic></p>
</list-item>
<list-item>
<p><italic>L. lainsoni</italic></p>
</list-item>
<list-item>
<p><italic>L. naiffi</italic></p>
</list-item>
<list-item>
<p><italic>L. panamensis</italic></p>
</list-item>
<list-item>
<p><italic>L. peruviana</italic></p>
</list-item>
<list-item>
<p><italic>L. pifanoi</italic></p>
</list-item>
<list-item>
<p><italic>L. shawi</italic></p>
</list-item>
<list-item>
<p><italic>L. utingensis</italic></p>
</list-item>
</list>
</list-item>
</list>
</list-item>
</list>
</sec>
</sec>
<sec id="s2-1-2">
<title>Major Subject Areas</title>
<p>This is an example of a bulleted list. eLife Major subject areas are taken from a controlled list:</p>
<list list-type="bullet">
<list-item><p>Biochemistry</p></list-item>
<list-item><p>Biophysics and Structural Biology</p></list-item>
<list-item><p>Cell Biology</p></list-item>
<list-item><p>Computational and Systems Biology</p></list-item>
<list-item><p>Developmental Biology and Stem Cells</p></list-item>
<list-item><p>Ecology</p></list-item>
<list-item><p>Epidemiology and Global Health</p></list-item>
<list-item><p>Genes and Chromosomes</p></list-item>
<list-item><p>Genomics and Evolutionary Biology</p></list-item>
<list-item><p>Human Biology and Medicine</p></list-item>
<list-item><p>Immunology</p></list-item>
<list-item><p>Microbiology and Infectious Disease</p></list-item>
<list-item><p>Neuroscience</p></list-item>
<list-item><p>Plant Biology</p></list-item>
</list>
</sec>
<sec id="s2-1-3">
<title>Multi-lists</title>
<list list-type="order">
<list-item>
<p>Here is an example of a list with multiple paragraphs and equations.</p>
<p>A discrete three-dimensional model space was generated (represented as a
three-dimensional matrix; <xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1A</xref>, left), with dimensions
corresponding to population µ, population σ, and f value.
Any given value in the matrix indicates P(f|μ,σ),
that is, the probability of a given frequency given a particular
μ and σ. The columns (all f values for a given μ
and σ combination; <xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1</xref>, upper-right) thus constitute
the forward model (by which stimuli are generated), and the planes (all
combinations of μ and σ for a given f value; <xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1</xref>, lower-middle) constitute the inverse model (by which
hidden parameters can be estimated from observed f values).</p>
</list-item>
<!-- UPDATE: this 2) below is in error - it creates a repeat on the html view and a space
on the PDF view. Should not be there -->
<list-item>
<p> 2) For each segment, the model was inverted for its particular f value,
yielding a two-dimensional probability distribution for the hidden
parameters (<xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1</xref>, lower-middle). Steps 3-6 were then worked
through for each stimulus segment in order, starting at the beginning of
the stimulus.</p>
</list-item>
<list-item>
<p>These probability distributions, for each segment subsequent to the most
recent estimated population change (as defined later), were multiplied
together, and scaled to a sum of 1. The resulting probability
distribution (<xref ref-type="fig" rid="fig2s1">Figure 2—figure supplement 1</xref>, lower-right) thus reflects parameter
probabilities taking into account all relevant f values</p>
</list-item>
<list-item>
<p>This combined parameter probability distribution was then scalar
multiplied with the full model space, in order to weight each of the
forward model columns (each corresponding to a particular parameter
combination) by the probability of that parameter combination being in
effect. The resulting weighted model space was then averaged across
parameter dimensions, to yield a one-dimensional (forward) probability
distribution, constituting an optimal prediction about the f value of
the next stimulus segment, provided a population change did not occur
before then. A probability distribution applicable if a population
change were to occur was calculated the same way, but without weighting
the forward model columns (so as to encompass every possible parameter
combination).</p>
</list-item>
<list-item>
<p>It was assumed that a population change occurred immediately prior to the
first stimulus segment. To infer subsequent population changes, for each
segment the probability of observing the present f value was compared
for the two probability distributions (the distribution assuming a
population change, and the distribution assuming no change),
that is, P(f|c) and P(f|~c), respectively, with c denoting
a population change. The probabilities were compared, in conjunction
with the known prior probability of a population change (1/8), using
Bayes’ rule, as stated in Equation 2:<disp-formula id="equ1"><label>(1)</label><mml:math id="m2"><mml:mrow><mml:mi>P</mml:mi><mml:mo>(</mml:mo><mml:mi>c</mml:mi><mml:mo>|</mml:mo><mml:mi>f</mml:mi><mml:mo>)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:mi>f</mml:mi><mml:mtext>|</mml:mtext><mml:mi>c</mml:mi></mml:mrow><mml:mo>)</mml:mo></mml:mrow><mml:mi>P</mml:mi><mml:mo>(</mml:mo><mml:mi>c</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>P</mml:mi><mml:mo>(</mml:mo><mml:mi>f</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p>
<p>Here, P(c|f) is the chance that a population change occurred at that
particular time. Given that P(c) is known to be 1/8, and P(f), the total
probability of the observed f value, can be rewritten
P(f|c)P(c)+P(f|~c)(1-P(c)), the above equation can be rewritten
as Equation 3:<disp-formula id="equ2"><label>(2)</label><mml:math id="m3"><mml:mrow><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:mi>c</mml:mi><mml:mtext>|</mml:mtext><mml:mi>f</mml:mi></mml:mrow><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mn>1</mml:mn><mml:mo>+</mml:mo><mml:mfrac><mml:mrow><mml:mn>7</mml:mn><mml:mi>P</mml:mi><mml:mo>(</mml:mo><mml:mi>f</mml:mi><mml:mo>|</mml:mo><mml:mo>~</mml:mo><mml:mi>c</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mi>P</mml:mi><mml:mo>(</mml:mo><mml:mi>f</mml:mi><mml:mo>|</mml:mo><mml:mi>c</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p>
</list-item>
<list-item>
<p>For each segment, the above calculation of P(c|f) was made not only with
respect to the immediately preceding segment, but also a number of
segments preceding that, up to a maximum of 4. Therefore, for segment t,
it was possible to conclude that a population change had occurred
immediately prior to t, t-1, t-2, t-3, or none of the above. A
population change was judged to have occurred at the time point with the
highest value of P(c|f), provided this value was greater than 0.5. Using
more than 4 lags did not appreciably alter the estimates obtained by
model inversion. Importantly, any retrospective inference of population
changes did not retrospectively alter any prior predictions generated by
the model (e.g. at time t, if a population change were inferred to have
occurred at time t-3 then the priors for t-2, t-1 and t were not
affected, but only the priors for t+1 onwards).</p>
</list-item>
<list-item>
<p>Once the above steps were worked through for each stimulus segment in
order, the optimal prior predictions were used to calculate the
perceptual inference variables of interest. Predictions themselves were
summarised by their mean (μ) and precision (1/variance). Changes
to predictions (Δµ) were calculated as the absolute change
(in octaves) in μ from one prediction to the next. Surprise (S)
was calculated as the negative log probability of the observed f value
given the prior prediction, and prediction error (irrespective of
prediction precision) was calculated as the absolute difference (in
octaves) between the observed f value and the mean of the prior
prediction. Mathematically, surprise is directly proportional to
prediction precision multiplied by prediction error. Finally, Δf
was calculated as the absolute difference between the current and
preceding value of f.</p>
</list-item>
</list>
</sec>
<sec id="s2-1-4">
<title>Research Organisms</title>
<p>This is an example of an ordered list, the "system" will default to numbers. eLife Research organsims are taken from a controlled list from the submission system:</p>
<list list-type="order">
<list-item><p><italic>Arabidopsis</italic></p></list-item>
<list-item><p><italic>B. subtilis</italic></p></list-item>
<list-item><p><italic>C. elegans</italic></p></list-item>
<list-item><p><italic>C. intestinalis</italic></p></list-item>
<list-item><p>Chicken</p></list-item>
<list-item><p><italic>D. melanogaster</italic></p></list-item>
<list-item><p><italic>Dictyostelium</italic></p></list-item>
<list-item><p><italic>E. coli</italic></p></list-item>
<list-item><p>Frog</p></list-item>
<list-item><p>Human</p></list-item>
<list-item><p><italic>M. mulatta</italic></p></list-item>
<list-item><p>Maize</p></list-item>
<list-item><p>Mouse</p></list-item>
<list-item><p><italic>M. thermophila</italic></p></list-item>
<list-item><p><italic>M. crassa</italic></p></list-item>
<list-item><p><italic>Neurospora</italic></p></list-item>
<list-item><p>None</p></list-item>
<list-item><p>Other</p></list-item>
<list-item><p><italic>O. fasciatus</italic></p></list-item>
<list-item><p><italic>P. falciparum</italic></p></list-item>
<list-item><p><italic>P. dumerilii</italic></p></list-item>
<list-item><p>Rat</p></list-item>
<list-item><p><italic>S. cerevisiae</italic></p></list-item>
<list-item><p><italic>S. pombe</italic></p></list-item>
<list-item><p><italic>S. enterica</italic>serovar Typhi</p></list-item>
<list-item><p><italic>S. pyogenes</italic></p></list-item>
<list-item><p>Virus</p></list-item>
<list-item><p><italic>Volvox</italic></p></list-item>
<list-item><p><italic>Xenopus</italic></p></list-item>
<list-item><p><italic>P. cynocephalus</italic></p></list-item>
<list-item><p>Zebrafish</p></list-item>
</list>
<p>However, additional research organisms can be added during the production process so this is not a controlled list once it is output from the editorial system.
The research organism "Other" is hidden from display on the eLife website.</p>
</sec>
</sec>
<!-- Update: Most asset IDs have changed. Please see elife-00666-supp1 and elife_file_naming_2016_08_25.md for complete list and explanation -->
<sec id="s2-2">
<title>Tables</title>
<!-- Update: Table ids have been changed from tbl to table
Table containing coloured text and cells crossing multiple rows. It is wide enough that it would appear in landscape orientation in the PDF file (Table 1)
UPDATE: Example of how to deal with spans in a citation. We cannot add the links to all the items and the HTML view will only link to the first one, so do
not add all rids to the xref as it does not work. Only add the first one -->
<p>This section is an example of different tables, there are four in total (<xref ref-type="table" rid="table1">Tables 1 to 3</xref> and an unnamed inline table).</p>
<table-wrap id="table1" position="float">
<label>Table 1.</label>
<caption>
<title>This is the title.</title>
<p>This is the caption: A table containing interesting formating that is large enough to require landscape orientation in the PDF.</p>