/
index.html
1260 lines (1059 loc) · 65.7 KB
/
index.html
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
<!DOCTYPE html>
<html>
<head>
<title>Portable Web Publications Use Cases and Requirements</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
shortName: "dpub-pwp-ucr",
editors: [
{ name: "Heather Flanagan",
url: "",
company: "Invited Expert",
companyURL: "https://www.rfc-editor.org" },
{ name: "Romain Deltour",
url: "",
company: "DAISY",
companyURL: "" },
{ name: "Dave Cramer",
url: "",
company: "Hachette Livre",
companyURL: "http://www.hbgusa.com/" }
],
previousMaturity: "",
previousPublishDate: "",
wg: "Digital Publishing Interest Group",
wgURI: "http://www.w3.org/dpub/IG/",
wgPublicList: "public-digipub-ig",
wgPatentURI: "",
noRecTrack : "true",
otherLinks: [
{
key: "Repository",
data: [{
value: "Github Repository",
href: "https://github.com/w3c/dpub-pwp-ucr"
}]
},
{
key: "Issues tracker",
data: [{
value: "Github Issue Tracker",
href: "https://github.com/w3c/dpub-pwp-ucr/issues"
}]
}
],
edDraftURI: "http://w3c.github.io/dpub-pwp-ucr/",
};
</script>
<style media="screen">
ul.use-cases::before {
content: "Usage examples:";
font-weight: bold;
font-style: italic;
text-decoration: underline;
}
</style>
</head>
<body>
<section id='abstract'>
<p>
A Portable Web Publication is a collection of content items (e.g.,
pages, chapters, modules, articles) whose content is compatible with
Web usage, and structured as a single, self-contained logical unit.
This document describes the use cases that inform the requirements
for a Portable Web Publication, and should be read as part of the
<a href="https://www.w3.org/TR/pwp/">Portable Web Publications for
the Open Web Platform</a>.
</p>
</section>
<section id='sotd'>
<p>
This document is a Work In Progress.
</p>
</section>
<section>
<h2>Introduction</h2>
<p>The printed book has had hundreds of years of design refinement: we have developed and optimized page and book sizes and orientation, typesetting conventions, optimal margins and page layout. Readers in turn have grown used to the powerful affordances built into this information delivery technology: how we read books, use them, shelve them, own them, share them, and archive them.</p>
<p>In parallel, the Web has developed with its own set of design principles and user-expectations: for ubiquity and speed of access and discovery, for the ease of linking information from one source to another, and for the simplicity of publishing anything, quickly.</p>
<p>This Portable Web Publications Use Cases document is an effort by the W3C and the Digital Publishing Interest Group to articulate how these two design traditions work together to produce something more powerful, a fully accessible format which marries the bounded coherence of the printed book, with the open, networked spirit of the Web that can be used seamlessly online and offline.</p>
</section>
<section>
<h1>Fundamental Features of a PWP</h1>
<section>
<h2>Authors’ and readers’ requirements</h2>
<section>
<h3>The publication should be readable in a browser</h3>
<p>Reading long form publications should not be restricted
to specific devices or applications but should be equally
available in a browser.</p>
<ul class="use-cases">
<li>Bob has some very specific plugins in his browser
that he enjoys using for, e.g., annotation using his
own annotation server, or quickly copy and publish
extracts in a specialized social service. That means
that he wants to be able to read his textbook in this
environment, enjoying the environment he is familiar
with, rather than being forced in to a special
application for the purpose of that specific
publication</li>
<li>Alice reads a scholarly paper that refers to large
datasets. The data can be presented interactively
through some very specialized data visualization
services relying on custom hardware on her computer.
These visualization services are incorporated into her
browser and can be used from within a web page. Alice
wants to make use of these wile reading her paper to
gain a better understanding of the content.</li>
</ul>
</section>
<section>
<h3>The publication should conform to all the requirements of
the horizontal dependencies</h3>
<p>Reading a publication needs to conform to all of the
<a href="https://www.w3.org/Guide/Charter.html#horizontal-review">horizontal dependencies</a>
common to all specifications: accessibility,
internationalization, mobility, device independence,
privacy, security, and technical architecture principles.</p>
<p>Several of these requirements have their own sections with
use cases defined below.</p>
<ul>
<li><a href="#accessibility">Accessibility</a></li>
</ul>
<ul class="use-cases">
<li>Asmait uses a dedicated braille e-reader capable of
using standard Open Web technologies, that can render
any WCAG-compliant content. She needs to be able to
read her newspaper on her dedicated braille reader, not
just a standard browser and computer combination.</li>
</ul>
</section>
<section>
<h3>PWPs should be able to make use of all facilities
offered by the Open Web Platform</h3>
<p>There is a formidable development of visualization systems,
interactive tools, and other powerful facilities that are
built on top of the Open Web Platform, including accessing
external services like Wolfram Alfa. These tools have
been traditionally developed for browsers, and provide
possibilities that traditional publications (books,
magazines, scholarly papers, educational materials, etc.)
should also benefit from. That requires publications to
become first class citizens on the Web platforms. </p>
<ul class="use-cases">
<li>For scholarly publishing, Web-only publications
gradually become part of the mainstream (e.g., the
multidisciplinary
<a href="http://www.plosone.org">PLOS ONE</a> or the
new
<a href="https://peerj.com/computer-science/">PeerJ
CompSci</a> journals) with the main content being
published using traditional Web technologies like
HTML and CSS. These publications increasingly use
additional media such as video, audio, animated
graphics, or very large images, and the trend is
to consider these as integral parts of the
scientific output. (
<a href="http://bost.ocks.org/mike/algorithms/">Mike
Bostock’s recent article on visualizing
algorithms</a> or the “live” presentation of data
in a <a href="http://f1000research.com/articles/3-176/v2">
paper published by F1000 Research</a> are good
examples for the new possibilities.) This means
the publications need access to the latest
visualization, data management, etc, tools that
the Open Web Platform based tools can offer.</li>
<li>Educational materials are increasingly making use
of Open Web Platform facilities. They include
runnable program snippets, interactive testing tools
(linked to online evaluation facilities); in many
respect, the borderline between these publications
and Web Applications is becoming fuzzy.</li>
<li id="in_house_doc">A special form of document are
“in-house” documents, whose production is related to
technical and/or user documentation of complex
products as well as complex administrative documents.
The sheer quantity and complexity of production, as
well as confidentiality requirements, mean that the
production are done in-house. In many respects major
corporations such as IBM, Intel, Renault, or Boeing,
or institutions like the European Commission, the FAO,
or the UNESCO have become specialized publishers
themselves. The quantity of documentation makes it
infeasible to produce these documents in print (or
print-only); instead, publishing them on the public
Web, an Intranet, and/or providing them through
specialized mobile devices is the viable alternative.
The production of these documents has similar
challenges to scholarly publications like
accessibility issues, portability of annotations, or
the possible inclusion of complex media.</li>
</ul>
</section>
<section>
<h3>It should be possible to see the publication in a
“paginated” view</h3>
<p>Whereas a “scrolling” view is the dominating approach on
the Web in Web browsers, publications must provide the
possibility to switch to a paginated view if the user so
desires or as the author suggests. Pagination may
automatically adapt page sizes to the device’s or the
browser’s viewport, and may contain separate headers,
footers, possibly page numbers.
</p>
<p>For more detailed requirements on pagination, see <a href="https://www.w3.org/dpub/IG/wiki/Pagination_Requirements">here</a>.</p>
<ul class="use-cases">
<li>Ann reads the War and Peace which, when printed, is
over 1200 pages. For usability reasons (e.g., to give
her a better sense of where she “is” within the book,
to give her a bounded view of a portion of the text
that would help her navigate) she decides to switch her
reading environment to paged view to enjoy the novel.</li>
<li>The author of a history book has carefully crafted,
using CSS, images, flexboxes, etc., the book on the
history of a city so that each major milestone is
defined as a standalone unit that would be a single
page when printed, with a timeline with the main
events in the footer area of the page.</li>
<li>Fatima wants to choose between a scrolled view and a paginated
view of content that extends across multiple html documents.</li>
<li>A publisher wants to provide transition effects between pages, both within and across content documents.</li>
<li>A classroom teacher says, “turn to page 137 of your textbook,” and students with both print and digital editions need to find the same text.</li>
</ul>
</section>
<section>
<h3>The same PWP content may have to be accessed both online
and offline</h3>
<p>The <em>same</em> content of the PWP should be accessible
offline, if circumstances so dictate, without the necessity
for the reader to take any particular, technical actions.</p>
<ul class="use-cases">
<li>Connectivity as a commodity; students reading a
'digital textbook' in a remote locale should be
prepared for the fact that the connection may not be
reliable and thus an online experience not available.</li>
<li>Many institutions, such as schools and government
organizations (even in the wealthiest countries), do
not have the resources to update equipment frequently.
Therefore, it is necessary for publications to be
accessible on current as well as older browsers.</li>
<li>Readers, who can enjoy reading their favourite book
on their portable device in their home countries would
find it prohibitive to do the same while travelling, due
to very high mobile network access roaming charges.</li>
<li>Users want to cultivate private collections of
publications to own in private libraries that are
available to them whether online or offline,
over the public Internet or within a private LAN.</li>
<li><a href="#in_house_doc">“In house” documents</a> may
have to be accessed both online and offline, depending
on the access point. While online access might be
beneficial when done from the work floor (e.g., at an
airplane production line), the same documents may need
reliable offline access (e.g., in the cockpit).</li>
</ul>
</section>
<section>
<h3>There should be a very smooth transition between offline
and online states of the same publication</h3>
<p>Accessing a document online or offline should not be made
through conversions from one storage format to the other,
but should be as transparent as possible to the reader,
requiring only a very minimal (ideally no) interaction from her part.
</p>
<ul class="use-cases">
<li>Reviewing a scholary publication is an essential facility. In practice, reviewing is often done offline (e.g., in a plane, while commuting on a train, etc.). Reviewing means annotations, notes, highlights, possibly changes on the content itself. These annotations and changes should not be bound to a specific device used at the time of reading; they should be smoothly transferred to, e.g., the server of the journal when back online.</li>
<li>Many publications—especially long form fiction and non-fiction—that users engage with for many hours. During this time, the user may shift states in many ways—starting consumption on an internet enabled PC, moving to an internet enabled portable device, going into offline-mode on that device, and then back to the PC. Ensuring a smooth transition also means that bookmarks, current reading position, etc, are stored, without the need of a central server that may lead to privacy concerns.
</li>
</ul>
</section>
<section>
<h3>It should be possible to create and distribute as a
uniquely identified resource single unit.</h3>
<p>A PWP, no matter how many pieces, must be distributable
to readers or consumers as a single unit for distribution
so that users can consume the necessary content that is
identified by the PWP.</p>
<ul class="use-cases">
<li>A publisher needs to distribute content
in a consumable format to consumers.</li>
<li>A user wants to consume content on a multitude of
devices, some of which may not always have
connectivity. Having all required content grouped in
a logical structure that can be easily transferred will
meet the consumer’s expectations. </li>
<li>A user wants to share a publication with a friend.
For non-technically savvy people, doing this with a
large set of resources becomes complicated, whereas
being able to do that with a single unit (e.g., a
file).
<li>See also the section on archiving for further use
cases.</li>
<li>If the publication has to be checked for integrity
(e.g., through checksums), doing it for a single unit
(e.g., a file) may be more efficient rather than doing
it for all the constituents separately </li>
</ul>
</section>
<section>
<h3>A publication may consist of a collection of Resources</h3>
<p>A Portable Web Publications would, usually, consists of
a (possibly large) number of Web Resources, like HTML,
SVG, or CSS, and it may also contain data files, or
executable resources like JavaScript, iPython scripts, or
Java. This reflects the current practice on the Web,
emphasizing the need of memory requirement on small
devices, cacheability, or independent development.</p>
<ul class="use-cases">
<li>Publisher “P” works with multiple authors to create
an anthology and uses resources from different
locations on the web. Following the current practice
on the Web, the publication consists of many different
resources (HTML, SVG, CSS, etc.), with some of the
HTML contents formatted by, possibly, different CSS
files. The publisher needs the collection of all the
resources as a unit to include it into its business
workflow. </li>
<li>A book on wines that can be read from A-Z, or
personalized to only read about red wines or wines
from a specific region. Each wine may be a
resources/small chunk of data that is used to generate
the corresponding HTML content on the fly.</li>
<li>User “A” has access to materials only through an
old computer in her local library. While she has time
to read the entire copy of War and Peace, the system
is unable to display the entire resource as one huge
HTML file. Parsing through one 1200-page HTML document
is difficult and resource-intensive. Parsing through a
package of 60 HTML documents, roughly 20 pages each,
is less resource-intensive.</li>
<li>Content may have significantly different styles between files. For
instance, some Japanese books will have documents whose root element
is vertical-rl and others whose root element is horizontal-tb. These
root element styles must be preserved.</li>
</ul>
</section>
<section>
<h3>The notion of a PWP should enable specific publications
like audio books, graphics books.</h3>
<p>All concepts, structures, etc, related to PWP should
enable the creation and/or production of video or audio
rendering; all the audio, video, sync, etc. content must
be part of the content the same PWP just as all the
other resources.</p>
<ul class ="use-cases">
<li>Users want to access audio books when commuting,
jogging, doing dishes, or otherwise not able to use
their eyes or hands. </li>
<li>Children’s book are a in huge demand, and they are
usually based on rich media like audio and video.
<li>See also section on accessibility.</li>
</ul>
</section>
<section>
<h3>Reader must have the possibility to personalize his/her
reading experience</h3>
<p>The user/reader should be able to control such features
as font size, choice of fonts, background and foreground
color, tone of voice, etc. This should be done via a proper
interactive dialogue and/or a choice among author-defined
possiblities.</p>
<ul class="use-cases">
<li>Olga, a dyslexic student, downloads a textbook and
proceeds to personalize the material with larger font
and different contrast.</p>
<li>When reading a book in the sun, a user adjusts the
background color to a dark color so that she can see the
text.</li>
<li>While reading a book on computer programming, Ransheed
wants to change the font into a local font. However, the
code should remain in a fixed-width font.</li>
<li>Mia choses to read in night mode because she finds it
easier to sleep when she puts the PWP aside.</li>
</ul>
</section>
<section id="versioning">
<h3>There should be a way to control versioning and revisioning</h3>
<p>There should be the capability for providing revisions
or new versions to users. The online and offline version
should be able to be in sync.</p>
<ul class="use-cases">
<li>The publisher may have pushed a new version of a
publication while Alice was accessing the offline
version. When getting back on line, Alice should have
the option of automatically synchronizing her offline
version with the update.</li>
</ul>
</section>
<section>
<h3>PWP treated as a single unit</h3>
<p>User agents must treat a PWP as a single unit as opposed
to individual documents. </p>
<ul class="use-cases">
<li>User agent must be able to search a complete PWP as
one unit.</li>
<li>User agent must be able to give value counters (page
counters, section numbering, footnotes, endnotes) across
the PWP (as opposed to individual components being
numbered separately)</li>
<li>User preferences apply to complete PWP (users must be
able to adjust display, e.g., font selection, font-size
adjustment, background color)</li>
<li>Assistive Technology such as screen readers or voice dication control needs to access a complete PWP.</li>
<li>A user should be able to access all linear content through simple UI gestures, independent of the document structure.</li>
</ul>
</section>
<section>
<h3>There should be a way to differentiate between essential
and non-essential resources</h3>
<p>When changing the state of a PWP from, e.g., online to
offline, an implementation may have to know which PWP
resources are essential for the display of the content, and
therefore must be included in the offline version, or which
may be skipped</p>
<ul class="use-cases">
<li>A mathematical font is essential for the proper display
of a mathematical formula; it is therefore essential to add
that font to the set of resources that are made available
offline.</li>
<li>A font used for aesthetic purposes only in display of a
book may not be essential and an implementation may decide
not to embed it for offline use.</li>
<li>Extended image descriptions may be essential for some
users and included for offline use.</li>
<li>A large dataset referred to from a scholarly journal
article may not be essential for conveying the results of
the paper and can therefore be skipped when an offline
version is produced to save space in a mobile device. </li>
</ul>
</section>
<section>
<h3>Access control and write protections</h3>
<p>A PWP should allow for access control and write protections of
the resource.</p>
<ul class="use-cases">
<li>A library may loan the publication for 2 weeks; the PWP
should provide means for its environment to control the
period of the loan.</li>
<li>A university may make a textbook available for its
students for the course of the year.</li>
<li>Alice is working on potentially Nobel prize winning
research, and has drafted her paper describing her
discoveries. She asks Bob to review the paper, but
needs to make sure that the PWP retains specific
protections, regardless of whether it is read online or
offline.</li>
</ul>
</section>
</section>
<section>
<h2>Implementation requirements</h2>
<section id="find-information">
<h3>Find the information on the constituent resources of a PWP easily</h3>
<p>A PWP will likely be composed of multiple web documents. A
more complicated PWP may have many more components, meaning
that extracting in advance all the references to other
constituent resources may be prohibitive. It is therefore
necessary for the reading system to have an easy access to
the list of constituent resources, and some of their characteristics like their media types or sizes.
</p>
<ul class="use-cases">
<li>The system needs to identify which components need to
be downloaded to a local user’s device to support offline
reading</li>
<li>The system needs to preload some document components
in order to provide a more responsive reading experience.</li>
<li>When creating a packaged publication it must be clear
which documents should or should not be added to the
distribution package</li>
<li>The size of the components will need to be known in
advance.</li>
<li>The reading systems needs to know if a publication contains/requires support for a specified media type (without processing all content documents).</li>
</ul>
</section>
<section id="reading-order">
<h3>Find the (default) reading order of the resources of a PWP easily</h3>
<p>A user agent needs to know the sequence in which to present
components of a PWP to the user. A PWP will likely be
composed of multiple web documents. A typical simple PWP will
anywhere from 1 to 15 HTML documents and several image files,
in one location or many. A more complicated PWP may have many
more components, meaning that extracting the exact order from
within the resources (i.e., parsing them in advance to extract
the information) may be prohibitive. It is therefore necessary
for the reading system to have an easy access to the reading
order constituent resources. In particular, the user agent should also have the information on what the starting point of the publication rendering is.
</p>
<ul class="use-cases">
<li>Moby Dick contains 136 chapters. Each chapter is a
separate HTML document. The user agent must present the
chapters sequentially, starting by the first chapter.</li>
<li>The Encyclopedia of Stuff includes 1348 articles, each
one in a unique HTML document. The user agent must
present the articles in order (alphabetically, by title).
</li>
</ul>
</section>
<section id="unique-identifier">
<h3>There should be a way to uniquely identify a publication
regardless of its state</h3>
<p>A unique identification of a specific publication,
regardless of whether it is online or offline, or whether it
is part of a web site or a single (packaged) file is
essential. This unique identification should be mapped onto
the “real” location of the publication smoothly, without the
author’s interaction.
</p>
<ul class="use-cases">
<li>Digital publications make use of interactive cross
references within the publication (references to indeces,
images, etc). These references should be done once by
the author and should work regardless of whether the
publication is online or offline, for example.
</li>
<li>Scholarly references demand a unique identification
of the publication and, possibly, it internal structure.
That unique identification must be available as a Web link,
to make it possible for other publications and other
sites (e.g., the authors’ institutional sites) to
unambigously link to the publication. These features
are essential in the scholarly community to make, for
example, the assessment of individual researchers
possible.</li>
</ul>
</section>
</section>
</section>
<section>
<h1>Changing State</h1>
<section>
<h2>State Changing Document</h2>
<p>Many publications - especially long form fiction and non-fiction - that
users engage with for many hours. During this time, the user may shift
states in many ways - starting consumption on an internet enabled PC,
moving to an internet enabled portable device, going into offline-mode
on that device, and then back to the PC.</p>
<ul class="use-cases">
<li>The user needs to ensure they have
access to critical pieces of data while secondary assets have a pre-
defined fallback that will allow the user to continue (for example, a
poster image of a video that serves as a placeholder for an externally
streamed video when internet is available).</li>
<li>Nick is reading
long-form narrative non-fiction. A publication filled with text, images,
sounds, and multi-media files. Nick is also a multi-device user who
wishes to consume the publication on multiple devices. Some of those
devices have limited storage, and some of them have limited connectivity.
Nick also rides the subway - where he loses internet connection, without
warning - for long stretches of time.</li>
<li>During offline or low-storage situations, there are still critical parts
of the publication that are consumable - mainly the text (and possibly
images). Having a reasonable fallback for video (a poster image or
placeholder image) would allow Nick to read the content while offline or
in limited storage. While this should be the job of the reading system,
having a method in the publication for the author of the publication to
mark what items are critical, and what need a fallback for limited
connectivity/storage situations would greatly help the reading system and
give more control to the publisher to ensure consistent experience with
consuming the publication.</li>
<li>Nick may know he's going to be in a no-connectivity situation and may
want to obtain and locally store the entire (even non-critical) contents.
This would be up to the reading system to provide a mechanism, but having
a way to denote critical and fallback assets ensures that an entire
package isn't downloaded when not necessary.</li>
<li>For the case of scripting - it's possible that certain items will be
dynamic - and will hit an external resource (or server) to generate
on-the-fly data. In offline mode, the user would want to be alerted that
content could not be obtained, or be shown some fallback set of data. In t
his case, being able to specify a "no-connectivity" or "offline-mode"
alternative for scripts would allow the publication author to have more
control over the user's experience and replace a potential error-display
with a limited subset of a good experience.</li>
</ul>
</section>
<section>
<h2>Annotating Across States Via a Reader Plugin</h2>
<p>TBD (note that we'll need to clean up and/or clarify what
packed and unpacked mean in this context)</p>
<ul class="use-cases">
<li>Writer Annie has her book published on her own web space as a PWP
[http/packed]. Reader Bob opens it online using the PWP reading plugin
PWPRead-plugin, and selects a nice quote to bookmark via PWPMark-plugin.</li>
<li>Writer Annie has her book published on her own web space as a PWP
[http/packed]. Reader Bob caches it using a plugin [cache/packed],
and selects a nice quote to bookmark via PWPMark-plugin.</li>
<li>Writer Annie has her book published on her own web space as a PWP,
both packed [http/packed] as unpacked [http/unpacked]. Reader Bob
reads [http/unpacked] online and selects a nice quote to bookmark
via PWPMark-plugin. Then, Bob downloads [http/packed] to his local
filesystem [file/packed] to open in his reading system of choice,
namely, PWPRead-soft.</li>
<li>PWPRead-soft synchronizes with Bob's PWPMark profile, and can
show Bob's bookmarks when he continues reading [file/packed]</li>
</ul>
</section>
<section>
<h2>Annotating Across States Via a Browser Plugin</h2>
<p>TBD (note that we'll need to clean up and/or clarify what
packed and unpacked mean in this context)</p>
<ul class="use-cases">
<li>Writer Annie has her book published on her own web space as a PWP
[http/unpacked]. Reader Bob reads it online, and selects a nice quote
to bookmark via its browser PWP bookmarking plugin: PWPMark-plugin.</li>
<li>When Bob re-opens the PWP offline, the bookmarks are shown via
PWPMark-plugin</li>
<li>When Bob re-visits the original PWP, PWPMark-plugin can also show
Bob's bookmarks in the online version.</li>
</ul>
</section>
</section>
<section>
<h1>Sharing, Distribution, and External Resources</h1>
<section>
<h2>Distribution</h2>
<p>Multiple distribution points and reader devices for a PWP should not result in
multiple versions of a PWP.</p>
<ul class="use-cases">
<li>Publisher Corp. Inc. publishes a new PWP, and sends this PWP to ACME
its customers. This PWP is downloaded to devices, or synced across
several devices, or made available to a customer-specific cloud.
Customers can access this file from different retailers, through different
applications, either directly or downloaded from private cloud. Thus, the
PWP is duplicated many, many, many, many, many times, resulting in a huge
number of items. There is one source manifestation, one ISBN identifier,
and lots of items spread across devices and buyers.</li>
</ul>
</section>
<section>
<h2>Retail (???)</h2>
<p></p>
<ul class="use-cases">
<li>(e)books that are sold need to be delivered, so that purchasers can load
them on offline devices.</li>
<li>Purchased content has different expectations - one being that you have
“something” or a reasonable use of that content in a logical way (such as
always being able to read your amazon purchases through the amazon app)</li>
<li>Sales Auditing -> Ability to track “what” is sold so that it can be paid.
If all content is just free and different chunks are purchased, chasing
rights/payments is an issue. Basically the package can have an ISBN
associated so that it can be tracked for sale - even multiple versions.</li>
</ul>
</section>
<section>
<h2>PWPs with Shared Resources</h2>
<p>Several PWPs may share identical resources.</p>
<ul class="use-cases">
<li>EsteemedPublisher creates apps to distribute several journals to readers.
These apps share script libraries, CSS files, and other resources.
Distributing many journals as a package should enable systems to call the
shared resources once, speeding up processing and enabling offline reading.
</li>
</ul>
</section>
<section>
<h2>Cross-references</h2>
<p>A user should have an option to pull their local copy of a PWP when
there is a choice between a local, annotated copy and third-party source.</p>
<ul class="use-cases">
<li>Writer Annie writes a dissertation. She references to her Master's
thesis, published on the university website. Her colleague Bob has
read her Master's thesis before. When he clicks the reference in
Annie's dissertation, he gets redirected to his local copy of Annie's
Master's thesis. Her friend, Charlie, hasn't read her Master's thesis
before. Charlie needs to be online when clicking the reference, to read
Annie's Master's thesis. </li>
</ul>
</section>
<section>
<h2>Publication with Static Data</h2>
<p>TBD</p>
<ul class="use-cases">
<li>Rosa submitted an article to EsteemedJournal and provided her research
data in CSV format. She and EsteemedJournal wish to provide users access
to the CSVs when they gain access to her article. EsteemedJournal
recommends that the package is built in such a way that a system can query
the manifest to assess whether it is situationally appropriate to offer
downloads. For example, the package might not offer the option to download
the CSV while a user is reading offline. </li>
</ul>
</section>
<section>
<h2>Publication with Interactive Data</h2>
<p>TBD</p>
<ul class="use-cases">
<li>(Extension to the Publication with Data use case): the article of Rosa
not only includes data, but also interactive graphics relying on that
data, with interaction directed through javascript (or other) programming
interfaces. These javascript programs may be fairly complex, and may also
rely on external libraries (not necessarily integrated into the article
itself). </li>
</ul>
</section>
</section>
<section>
<h1>Manifests</h1>
<p>In this document by <em>manifest</em> we mean an abstract place, typically one or several files, that contain information necessary to the proper management, rendering, etc, of the publication. This is opposed to <em>metadata</em> that contain information on the <em>content</em> of the publication like author, publication date, etc.</p>
<p>Some fundamental use cases and requirements already imply the usage of manifests, e.g.:</p>
<ul>
<li><a href="#find-information"></a></li>
<li><a href="#reading-order"></a></li>
</ul>
<section>
<h2>Manifests should include the basic characteristics of the constituent resources</h2>
<p>A user agent requires information about the package and its components in order to process it. E.g., performance and memory requirements may prevent a user agent from parsing a large number of content documents in order to discover the necessary components and their relationships. A user agent may need to make some decisions about how to present content before displaying it.</p>
<p>Some necessary features are listed among the fundamental features of a PWP (see <a href="#find-information"></a>); the use cases below provide a (non-exhaustive) list of further information.</p>
<ul class="use-cases">
<li>A user agent may not be able to process files beyond a certain size due to bandwidth, storage or memory limitations, or processing time expectations. Hence this information should be available in advance.</li>
<li>A user agent should be able to process permissions and rights information for each component identified in the package. For example, it need to know whether it has the rights to place an image of the Mona Lisa owned by the Louvre in a package to be downloaded offline.</li>
<li>For further processing the user agent needs to have access to a number of additional information like:
<ul>
<li>the accessibility of each component;</li>
<li>whether it needs additional processing instructions, such as with MathML;</li>
<li>the title, author(s), cover image, etc., to display the publication on a shelf without downloading all its content;</li>
<li>whether the content is unaltered;</li>
<li>the origin of the publication.</li>
</ul>
</li>
</ul>
</section>
<section>
<h2>The manifest should provide access to the general metadata of a publication</h2>
<ul class="use-cases">
<li>The manifest may be a "first point of entry" for the user agent when getting hold of a publication, and should therefore provide an easy way to get hold of the general publication metadata (e.g., author’s and publisher’s data, library data, copyright information, etc.)</li>
</ul>
</section>
<section>
<h2>Manifest should make it possible to provide a streamlined access to disjoint parts of the publication</h2>
<p>It should be possible for the author to convey several reading orders for the content of the publication, that may go beyond the “default” <a href="reading-order">reading order</a>. Furthermore, this alternative reading order may not necessary include the full content of the publication but only specific parts thereof.</p>
<ul class="use-cases">
<li>EsteemedJournalPublisher would like to offer the users of the EsteemedJournal of Chemistry App the opportunity to read only the abstracts of the journals in the app. The App Package must offer the user a list (table of contents) of abstracts (disjoint objects in the package with semantic information or metadata informing the package of the nature of the object). </li>
<li>The publisher wants to provide “teasers” for a book by providing a series of extracts that are meant to give an overview of the book without the necessity to read the whole publication. This can be typically used by a reseller allowing for a prospective client to access part of the publication free of charge.</li>
</ul>
</section>
<section>
<h2>Manifest should include information of new content</h2>
<p>The manifest should include information that makes it possible for a user agent to find out whether a specific content has changed since a last access or not. This may or may not directly reflect versioning, as referred to in the requirement on versioning (see <a href="#versioning"></a>), insofar as the granularity may be different.</p>
<ul class="use-cases">
<li>Shoshana is an organic chemist. She has purchased the Esteemed Journal of Chemistry App. She downloads Organic Chem Quarterly in her lab and reads the first article over lunch. Shoshana begins the book reviews during office hours but must tend to her students' questions, so she closes the app. Shoshana opens the app on the train ride home to resume reading the book reviews. She is happy to find that the app opens to the exact location and opens quickly because most of the material does not need to be downloaded a second time. </li>
<li>An archival service needs to update an Archival Information Package (i.e., a previously harvested PWP) because a new version of a component of the PWP has been published</li>
</ul>
</section>
<section>
<h2>Manifest should include means to use links to resources, regardless of location</h2>
<p>The fundamental requirement on identification already states that there should be a way to uniquely identify a publication (see <a href="#unique-identifier"></a>). This requirement should be extended to resources <em>within</em> a publication, e.g., a chapter, an image, a mathematical formula. To achieve these, the manifest should contain the necessary information to make the mapping of URI-s possible.</p>
<ul class="use-cases">
<li>A scholarly mathematical publication refers to a specific theorem in another publication, and that reference must be unique, stable and retrievable on the Web. That reference should not depend on whether the publishes issues a new version of the target publication (thereby possibly change the section numbering) or whether the publication is available now for offline use.</li>
<li>An archival service wants to harvest (spider) a PWP, and expects to find in the manifest what it will need to make sure it gets all the pieces of the PWP that need to be archived, even if on separate servers.</li>
</ul>
</section>
<section id="alternative-reading-order">
<h2>Manifest may include alternative reading orders</h2>
<p>Whilst one of the fundamental requirements is that the default reading order should be made available to the user agent (see <a href="#reading-order"></a>), the manifest should also provide means to define alternative reading orders. It is up to the user agent how this alternative reading order is conveyed to the reader (via some suitable user interface techniques).</p>
<ul class="use-cases">
<li>EducationalPublisher publishes a complex textbook. The textbook is created is such a way that it could be used both for beginner and advanced level. The default reading order corresponds to beginners, but the goal is that advanced students can follow a different path through the material, corresponding to their level of knowledge. EducationPublisher adds, therefore, alternative reading orders to the publication that advanced users can follow</li>
</ul>
</section>
<section id="flexible-access-manifest">
<h2>There should be flexible ways to get hold of the manifest for a publication</h2>
<p>The physical realization of the manifest may be a file in some predefined format (XML, JSON, etc.). There may be several ways to get hold of that manifest (file on a well known location, usage of an HTML <code>link</code> element, etc). PWP should provide a high level of flexibility, i.e., possible alternatives, on how that manifest should be found.
</p>
<ul class="use-cases">
<li id="bigretailer-manifest">BigRetailer receives a publication from EsteemedPublisher that it intends to add to its catalogue. BigRetailer wants to change or extend some general information (typically contained in the manifest) regarding the publication, like the local bibliographic metadata, or its own “teaser” in terms an alternative reading order (see <a href="#alternative-reading-order"></a>). To achieve that, BigRetailer provides its own version of the publication manifest, and makes it sure that the user agent takes that one as the publication’s manifest (e.g., by providing a reference to the alternative manifest via an HTTP <code>LINK</code> header).</li>
</ul>
</section>
<section>
<h2>There should be a possibility to combine manifests from several origins</h2>
<p>The default approach for a user agent is to get hold of the manifest (file) as one unit via some flexible means (see <a href="#flexible-access-manifest"></a>). However, an even more flexible means is to provide possibilities to provide <em>several</em> manifests file that the user agen would combine, following some rules, to yield the final, overall manifest for the publication.
</p>
<p class="note">
It is recognized that the proper definition/implementation of this requirement may lead to major technical complications and, therefore may not be fulfilled.
</p>
<ul class="use-cases">
<li>The simple solution for the <a href="#bigretailer-manifest">use case involving BigRetailer</a> requires the creation of a <em>complete</em> manifest, involving duplicating the information provided the EsteemedPublisher. This is obviously error prone if the publication’s manifest is large. If it was possible to combine manifests, BitRetailer can only provide its own additional (and possibly replacement) information and let the user agent combine the manifests of BigRetailer and of EsteemedPublisher to yield the final manifest.</li>
</ul>
</section>
</section>
<section>
<h2>Packaging</h2>
<p>TBD</p>
<p>From the manifest part: "Package should include a queryable manifest."; to be added here?</p>
</section>
<section>
<h1>Locators</h1>
<section>
<h2>General locators</h2>
<p>TBD</p>
<ul class="use-cases">
<li>A state-independent locator should be part of the PWP.</li>
<li>There MUST be a separation between a format-independent
(“canonical”) and format-dependent locator.</li>
<li>It SHOULD be possible to use, in all circumstances, a relative
locator to manipulate, annotate, etc, content in a PWP</li>
<li>Locating a resource within a PWP should not depend on the PWP's
state.</li>
<li>There needs to be persistence of identifiers across PWP instances.</li>
</ul>
</section>
<section>
<h2>Canonical versus non-canonical</h2>
<p>TBD</p>
<ul class="use-cases">
<li>It MUST be possible (and necessary) to use, for all cross-references,
the canonical locator.</li>
<li>There MUST be a separation between the identifier (e.g., ISBN) and
the (canonical) locator of a specific instance of a PWP.</li>
<li>The Identifier (e.g., ISBN) MAY serve as a canonical locator for a
specific instance of a PWP</li>
<li>Any set up and mechanism, handling canonical and state-dependent
locators, MUST be easily settable on any server (albeit maybe not
in the most efficient manner) based on basic server behavior
control.</li>
<li>A PWP Processor MUST be able to combine a relative locator with
the canonical as well as state dependent locators of a PWP</li>
</ul>
</section>
</section>
<section>
<h1>Archival Interest</h1>
<section>
<h2>Integrity and Longevity</h2>
<p>TBD</p>
<ul class="use-cases">
<li>A government agency (e.g., laws, regulations, judicial decisions) publishes
information that need to persist without any loss of information
forever.</li>
<li>Journal article (e.g., announcing novel compound in chemistry) must be
published in method that is persistent because it serves at the document of
record for scientific record. </li>
</ul>
</section>
<section>
<h2>Retraction Notices</h2>
<p>TBD</p>
<ul class="use-cases">
<li>An archival service needs to harvest the retraction notice and update the
Archival Information Package for the original PWP to include / link to the
Retraction Notice.</li>
</ul>
</section>
<section>
<h2>Take-down Notices</h2>
<p>TBD</p>
<ul class="use-cases"?
<li>An archival service needs to update an Archival Information Package (i.e.,
a previously harvested PWP) because it or one of its components has been
taken down by the publisher.</li>