This
specification
defines
a
collection
of
information
that
describes
the
structure
of
Web
Publications
so
that
user
agents
can
provide
user
experiences
tailored
to
reading
publications,
such
as
sequential
navigation
and
offline
reading.
This
information
includes
the
default
reading
order,
a
list
of
resources,
and
publication-wide
metadata.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/wpub/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
This
draft
provides
a
preliminary
outline
of
a
Web
Publication.
Many
details
are
under
active
consideration
within
the
Publishing
Working
Group
and
are
subject
to
change.
The
most
prominent
known
issues
have
been
identified
in
this
document
and
links
provided
to
comment
on
them.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
A
Web
Publication
is
a
discoverable
and
identifiable
collection
of
resources.
Information
about
the
Web
Publication
is
expressed
in
a
machine-readable
document
called
a
manifest
,
which
is
what
enables
user
agents
to
understand
the
bounds
of
the
Web
Publication
and
the
connection
between
its
resources.
The
manifest
includes
metadata
that
describe
the
Web
Publication,
as
a
publication
has
an
identity
and
nature
beyond
its
constituent
resources.
The
manifest
also
provides
a
list
of
all
the
resources
that
belong
to
the
Web
Publication
and
a
default
reading
order,
which
is
how
it
connects
resources
into
a
single
contiguous
work.
A
Web
Publication
is
discoverable
in
one
of
two
ways:
resources
either
include
a
link
to
the
manifest
(via
an
HTTP
Link
header
or
an
HTML
link
element [
html
]),
or
the
manifest
can
be
loaded
directly
by
a
compatible
user
agent.
With
the
establishment
of
Web
Publications,
user
agents
can
build
new
experiences
tailored
specifically
for
their
unique
reading
needs.
This
specification
only
defines
requirements
for
the
production
and
rendering
of
valid
Web
Publications
.
As
much
as
possible,
it
leverages
existing
Open
Web
Platform
technologies
to
achieve
its
goal—that
being
to
allow
for
a
measure
of
boundedness
on
the
Web
without
changing
the
way
that
the
Web
itself
operates.
Moreover,
the
specification
is
designed
to
adapt
automatically
to
updates
to
Open
Web
Platform
technologies
in
order
to
ensure
that
Web
Publications
continue
to
interoperate
seamlessly
as
the
Web
evolves
(e.g.,
by
referencing
the
latest
published
versions
instead
of
specific
dated
versions).
Further,
this
specification
does
not
attempt
to
constrain
the
nature
of
a
Web
Publication:
any
type
of
work
that
can
be
represented
on
the
Web
constitutes
a
potential
Web
Publication.
The
specification
is
also
intended
to
facilitate
different
user
agent
architectures
for
the
consumption
of
Web
Publications.
While
a
primary
goal
is
that
traditional
Web
user
agents
(browsers)
will
be
able
to
consume
Web
Publications,
this
should
not
limit
the
capabilities
of
any
other
possible
type
of
user
agent
(e.g.,
applications,
whether
standalone
or
running
within
a
user
agent,
or
even
Web
Publications
that
include
their
own
user
interface).
As
a
result,
the
specification
does
not
attempt
to
architect
required
solutions
for
situations
whose
expected
outcome
will
vary
depending
on
the
nature
of
the
user
agent
and
the
expectations
of
the
user
(e.g.,
how
to
prompt
to
initiate
a
Web
Publication,
or
at
what
point
or
how
much
of
a
Web
Publication
to
cache
for
offline
use).
1.3
Relationship
to
Other
Specifications
1.3.1
Web
App
Manifest
Editor's
note
We
may
want
to
write
something
here
on
the
relationships…
An
identifier
is
metadata
that
can
be
used
to
refer
to
Web
Content
in
a
persistent
and
unambiguous
manner.
URLs
,
URNs
,
DOIs
,
ISBNs
,
and
PURLs
are
all
examples
of
persistent
identifiers
frequently
used
in
publishing.
For
the
purposes
of
this
specification,
non-empty
is
used
to
refer
to
an
element,
attribute
or
property
whose
text
content
or
value
consists
of
one
or
more
characters
after
whitespace
normalization,
where
whitespace
normalization
rules
are
defined
per
the
host
format.
URL
The
general
term
URL
is
defined
by
the
URL
Standard [
url
].
It
is
used
as
in
other
W3C
specifications,
like
HTML
[
html
].
In
particular,
a
URL
allows
for
the
usage
of
characters
from
Unicode
following [
rfc3987
].
See
the
note
in
the
HTML5
specification
for
further
details.
Web
Publication
A
Web
Publication
is
a
collection
of
one
or
more
resources,
organized
together
through
a
manifest
into
a
single
logical
work
with
a
default
reading
order
.
The
Web
Publication
is
uniquely
identifiable
and
presentable
using
Open
Web
Platform
technologies.
2.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
OPTIONAL
,
RECOMMENDED
,
REQUIRED
,
SHOULD
,
and
SHOULD
NOT
are
to
be
interpreted
as
described
in
[
RFC2119
].
2.1
Conformance
Classes
This
specification
defines
two
conformance
classes:
one
for
Web
Publications
and
one
for
user
agents
that
process
them.
A
Web
Publication
conforms
to
this
specification
if
it
meets
the
following
criteria:
A
user
agent
conforms
to
this
specification
if
it
meets
the
following
criteria:
it
is
capable
of
generating
a
conforming
infoset
for
a
Web
Publication.
3.
Web
Publication
Construction
3.1
Infoset
and
Manifest
This
section
is
non-normative.
A
Web
Publication
is
defined
by
a
set
of
items
known
as
its
information
set
(
infoset
).
The
infoset
is
both
abstract
and
concrete.
It
is
abstract
in
the
sense
that
it
represents
a
set
of
information
that
a
user
agent
has
to
compile
about
the
Web
Publication,
but
it
also
becomes
concrete
when
the
user
agent
creates
an
internal
representation
of
that
information.
A
manifest
,
on
the
other
hand,
is
a
serialization
of
an
infoset
created
by
the
author
of
a
Web
Publication
.
The
manifest
is
expressed
using
the
JSON
-LD [
json-ld
]
format
—
a
variant
of
JSON
[
ecma-404
]
for
expressing
linked
data.
The
manifest
can
be
created
as
a
standalone
resource
or
it
can
be
embedded
within
an
HTML
document.
Although
the
infoset
is
primarily
compiled
from
a
Web
Publication's
manifest
,
some
information
is
obtained
outside
the
manifest.
The
table
of
contents,
for
example,
may
be
referenced
from
the
manifest
but
is
serialized
in
an
HTML
document.
This
specification
describes
the
requirements
for
creating
both
the
infoset
and
manifest.
This
section,
in
particular,
details
how
to
create
a
manifest,
and
the
next
lists
the
various
properties
common
to
infosets
and
manifests.
3.2
Creating
a
Manifest
3.2.1
Manifest
Contexts
A
Web
Publication
Manifest
MUST
start
by
setting
the
JSON
-LD
context
[
json-ld
].
The
context
has
the
following
two
major
components:
The
Web
Publication
context
file
MAY
add
features
to
the
properties
defined
in
Schema.org
(e.g.,
the
requirement
for
the
creator
property
to
be
order
preserving).
Note
As
part
of
the
continuous
contacts
with
Schema.org
the
additional
features
defined
in
the
Web
Publication
context
file
could
migrate
to
the
core
Schema.org
vocabulary.
Note
Although
Schema.org
is
often
referenced
using
the
http
URI
scheme,
the
vocabulary
is
being
migrated
to
use
the
secure
https
scheme
as
its
default.
This
specification
requires
the
use
https
when
referencing
Schema.org
in
the
manifest.
In
some
cases,
the
context
MAY
be
extended
by
additional,
local
information.
For
example,
see
4.4.5.2
Manifest
Expression
.
3.2.2
Publication
Types
The
Web
Publication
Manifest
MUST
include
a
Publication
Type
using
the
@type
keyword [
json-ld
].
The
type
MAY
be
mapped
onto
the
CreativeWork
type [
schema.org
].
Example 2: Setting a Web Publication's type to CreativeWork.
Schema.org
also
includes
a
number
of
more
specific
types,
all
subtypes
of
CreativeWork
,
such
as
Article
,
Book
,
and
Course
.
These
MAY
be
used
instead
of
CreativeWork
.
Example 3: Setting a Web Publication's type to Book.
Although
authors
only
have
to
understand
the
serialization
requirements
for
manifest
terms,
they
are
encouraged
to
read
through
the
infoset
definitions
for
each
property,
as
well.
The
infoset
definitions
describe,
in
some
cases,
how
items
are
compiled
in
the
absence
of
explicit
information
in
the
manifest.
When
embedding
a
manifest,
the
type
attribute
of
the
containing
script
element
MUST
be
set
to
application/ld+json
.
Additionally,
the
script
element
MUST
include
a
unique
identifier
in
an
id
attribute [
html
].
This
identifier
ensures
that
the
manifest
can
be
referenced
.
Example 4: A Web Publication Manifest included in an HTML document
Resources
SHOULD
provide
a
link
to
the
manifest
of
the
Web
Publication
to
which
they
belong
to
enable
discovery.
Links
MUST
take
one
or
both
of
the
following
forms:
An
HTTP
Link
header
field [
rfc5988
]
with
its
rel
parameter
set
to
the
value
"
publication
".
A
link
element [
html
]
with
its
rel
attribute
set
to
the
value
"
publication
".
Example
6
<
link
href
=
"https://example.com/webpub/manifest"
rel
=
"publication"
/>
When
a
manifest
is
embedded
within
an
HTML
document,
the
link
MUST
include
a
fragment
identifier
that
references
the
script
element
that
contains
the
manifest
(see
3.3
Embedding
a
Manifest
).
Example 7: Link to a manifest within the same HTML resource
The
exact
value
of
rel
is
still
to
be
agreed
upon
and
should
be
registered
by
IANA.
Editor's
note
The
following
details
might
be
moved
to
the
lifecycle
section
in
a
future
draft.
When
a
resource
links
to
multiple
manifests,
a
user
agent
MAY
choose
to
present
one
or
more
alternatives
to
the
end
user,
or
choose
a
single
alternative
on
its
own.
The
user
agent
MAY
choose
to
present
any
manifest
based
upon
information
that
it
possesses,
even
one
that
is
not
explicitly
listed
as
a
parent
(e.g.,
based
upon
information
it
calculates
or
acquires
out
of
band).
In
the
absence
of
a
preference
by
user
agent
implementers,
selection
of
the
first
manifest
listed
is
suggested
as
a
default.
The
manifest
may
be
embedded
into
the
primary
entry
page
;
in
this
case
the
link
element
MUST
use
a
relative
URL
to
refer
to
the
manifest.
The
manifest
itself
MUST
NOT
include
a
reference
to
itself,
i.e.,
the
reference
to
the
manifest
MUST
NOT
appear
as
part
of
the
4.7
Resource
Categorization
Properties
.
There
are
no
restrictions
on
a
Web
Publication
beyond
this
requirement.
The
Web
Publication
MAY
include
references
to
resources
of
any
media
type,
both
in
the
default
reading
order
and
as
dependencies
of
other
resources.
Note
When
adding
resources
to
a
Web
Publication,
consider
support
in
user
agents.
The
use
of
progressive
enhancement
techniques
and
the
provision
of
fallback
content,
as
appropriate,
will
ensure
a
more
consistent
reading
experience
for
users
regardless
of
their
preferred
user
agent.
3.6
Table
of
Contents
The
table
of
contents
provides
a
hierarchical
list
of
links
that
reflects
the
structural
outline
of
the
major
sections
of
the
Web
Publication.
The
table
of
contents
is
expressed
via
an
HTML
element
in
one
of
the
resources
(typically
a
nav
element [
html
]).
This
element
MUST
be
identified
by
the
role
attribute [
html
]
value
"
doc-toc
" [
dpub-aria-1.0
],
and
MUST
be
the
first
element
in
the
document
so
designated.
There
are
no
requirements
on
the
table
of
contents
itself,
except
that,
when
specified,
it
MUST
include
a
link
to
at
least
one
resource
.
Refer
to
the
table
of
contents
property
definition
for
more
information
on
how
to
identify
in
the
infoset
and
manifest
which
resource
contains
the
table
of
contents.
Issue
This
question
arises
only
if
the
table
of
contents
is
accepted:
can
a
table
of
contents
navigation
element
refer,
via
links,
to
any
resource
that
is
not
listed
in
the
default
reading
order
?
4.
Web
Publication
Properties
4.1
Introduction
This
section
is
non-normative.
Both
the
Web
Publication
infoset
and
manifest
are
defined
by
a
common
set
of
properties
that
describe
the
basic
information
a
user
agent
requires
to
process
and
render
a
Web
Publication.
These
properties
are
categorized
as
followed:
Descriptive
properties
describe
aspects
of
a
Web
Publication,
such
as
its
title
,
creator
,
and
language
.
These
properties
are
primarily
drawn
from
Schema.org
and
its
hosted
extensions
[
schema.org
],
so
they
map
to
one
or
several
Schema.org
properties
and
inherit
their
syntax
and
semantics.
(The
following
property
categories
typically
do
not
have
Schema.org
equivalents,
so
are
defined
specifically
for
Web
Publications.)
Informative
properties
identify
resources
that
contain
additional
information
about
the
Web
Publication,
such
as
its
privacy
policy
or
an
accessibility
report
.
Resource
categorization
properties
describe
or
identify
common
sets
of
resources,
such
as
the
resource
list
and
default
reading
order
.
These
properties
refer
to
one
or
more
external
resources
(images,
script
files,
separate
metadata
files,
etc.).
Note
The
categorization
of
properties
is
done
to
simplify
comprehension
of
their
purpose;
the
groupings
have
no
relevance
outside
this
specification
(i.e.,
the
groupings
do
not
exist
in
the
infoset
or
manifest).
Note
Schema.org
includes
a
large
number
of
properties
that,
though
relevant
for
publishing,
are
are
not
mentioned
in
this
specification;
Web
Publication
authors
can
use
any
of
those
properties.
This
document
defines
only
the
minimal
set
of
infoset
items,
and
their
mapping
to
Schema.org
when
appropriate.
Editor's
note
There
are
discussion
on
whether
a
best
practices
document
would
be
created,
referring
to
more
schema.org
terms.
If
so,
it
should
be
linked
from
here.
(Extracting
a
discussion
on
#232
into
a
separate
Issue.)
Schema.org
has
a
(currently
"pending")
type
LinkRole
which
may
be
a
good
alternative
to
the
(publication
specific)
PublicationLink
.
Maybe
worth
considering
using
the
schema.org
type.
As
the
infoset
properties
do
not
all
have
to
be
serialized
in
the
manifest,
the
requirements
for
the
manifest
will
differ
in
some
cases.
Refer
to
each
property's
definition
to
determine
whether
it
is
required
in
the
manifest
or
can
be
compiled
from
other
information.
4.3
Link
Values
With
the
exception
of
the
descriptive
properties
,
the
Web
Publication
properties
typically
link
to
one
or
more
resources.
When
a
property
requires
a
link
value,
the
link
MUST
be
expressed
in
one
of
the
following
two
ways:
as
a
string
encoding
the
(absolute
or
relative)
URL
of
the
resources [
url
];
or
as
an
instance
of
a
PublicationLink
object
that
can
be
used
to
express
the
URL
,
the
media
type,
and
other
characteristics
of
the
target
resource.
Example 8: Resource list includes one link using a string value ('datatypes.svg') and two that display the various properties of the a PublicationLink object
{
…
"resources" : [
"datatypes.svg",
{
"@type" : "PublicationLink",
"url" : "test-utf8.csv",
"encodingFormat" : "text/csv",
"name" : "Test Results",
"description" : "CSV file containing the full data set used in this research."
},
{
"@type" : "PublicationLink",
"url" : "terminology.html",
"encodingFormat" : "text/html",
"rel" : "glossary"
}
]
}
4.3.1
PublicationLink
Definition
This
specification
defines
a
new
type
for
links
called
PublicationLink
.
It
consists
of
the
following
properties:
The
relationship
of
the
resource
to
the
Web
Publication.
One
or
more
relations.
The
values
are
either
the
relevant
relationship
terms
of
the
IANA
link
registry [
iana-link-relations
],
or
specially-defined
URLs
if
no
suitable
link
registry
item
exists.
(None)
OPTIONAL
4.4
Descriptive
Properties
4.4.1
Accessibility
The
accessibility
properties
provides
information
about
the
suitability
of
a
Web
Publication
for
consumption
by
users
with
varying
preferred
reading
modalities.
These
properties
typically
supplement
an
evaluation
against
established
accessibility
criteria,
such
as
those
provided
in
[
WCAG20
].
(For
linking
to
a
detailed
accessibility
report,
see
4.5.1
Accessibility
Report
.)
4.4.1.1
Infoset
Requirements
The
following
infoset
items
are
categorized
as
accessibility
properties:
accessMode
accessModeSufficient
accessibilityAPI
accessibilityControl
accessibilityFeature
accessibilityHazard
accessibilitySummary
Note
More
detailed
descriptions
of
these
properties,
as
well
as
the
possible
values,
are
described
on
the
WebSchemas
Wiki
site
.
A
human-readable
summary
of
specific
accessibility
features
or
deficiencies,
consistent
with
the
other
accessibility
metadata
but
expressing
subtleties
such
as
“short
descriptions
are
present
but
long
descriptions
will
be
needed
for
non-visual
users”
or
“short
descriptions
are
present
and
no
long
descriptions
are
needed.”
Note
that
the
author
MAY
also
provide
a
reference
to
a
more
detailed
Accessibility
Report
,
beyond
the
accessibility
information
expressed
by
these
properties.
Example 9: Example for accessiblity metadata of a purely textual document
If
the
address
does
not
resolve
to
an
HTML
document [
html
],
user
agents
SHOULD
NOT
provide
access
to
it
to
users.
A
Web
Publication
MAY
have
more
than
one
address,
but
all
the
addresses
MUST
resolve
to
the
same
document.
The
referenced
document
SHOULD
be
a
resource
of
the
Web
Publication.
It
can
be
any
resource,
including
one
that
is
not
listed
in
the
default
reading
order
.
This
document
MUST
include
a
link
to
the
manifest
to
ensure
a
bidirectional
linking
relationship
(i.e.,
that
user
agents
can
also
locate
the
manifest
from
the
document
at
the
address).
If
the
document
is
not
a
Web
Publication
resource,
user
agents
SHOULD
load
the
first
document
in
the
default
reading
order
when
initiating
the
Web
Publication.
Note
To
improve
the
usability
of
Web
Publications,
particularly
in
user
agents
that
do
not
support
Web
Publications,
include
navigation
aids
in
the
referenced
document
that
facilitate
consumption
of
the
content,
(e.g.,
provide
a
table
of
contents
or
a
link
to
one).
Note
The
Web
Publication's
address
can
also
be
used
as
value
for
an
identifier
link
relation [
link-relation
].
A
Web
Publication's
canonical
identifier
is
a
unique
identifier
that
resolves
to
the
preferred
version
of
the
Web
Publication.
Note
Ensuring
uniqueness
of
canonical
identifiers
is
outside
the
scope
of
this
specification.
The
actual
uniqueness
achievable
depends
on
such
factors
as
the
conventions
of
the
identifier
scheme
used
and
the
degree
of
control
over
assignment
of
identifiers.
The
canonical
identifier
is
intended
to
provide
a
measure
of
permanence
above
and
beyond
the
Web
Publication's
address(es)
.
If
a
Web
Publication
is
permanently
relocated
to
a
new
URL
,
for
example,
the
canonical
identifier
provides
a
way
of
discovering
the
new
location
(e.g.,
a
DOI
registry
could
be
updated
with
the
new
URL
,
or
a
redirect
could
be
added
to
the
URL
of
the
canonical
identifier).
It
is
also
intended
to
provide
a
means
of
identifying
instances
of
the
same
Web
Publication
hosted
at
different
URLs
.
If
a
URL
is
not
provided
in
the
manifest,
or
the
value
is
an
invalid
URL
,
the
Web
Publication
does
not
have
a
canonical
identifier.
User
agents
MUST
NOT
attempt
to
construct
a
canonical
identifier
from
any
other
identifiers
provided
in
the
manifest.
Note
The
canonical
identifier
can
be
used
as
the
target
of
a
"canonical"
link [
rfc6596
]
(e.g.,
a
link
element [
html
]
whose
rel
attribute
has
the
value
canonical
or
an
HTTP
Link
header
field [
rfc5988
]
similarly
identified).
The
specification
of
the
canonical
identifier
MAY
be
complemented
by
the
inclusion
of
additional
types
of
identifiers
for
the
Web
Publication
using
the
identifier
property
[
schema.org
]
and/or
its
subtypes.
Example 11: Example for setting both the canonical identifier as URL and the address of the same document
Each
textual
The
Web
Publication
has
a
natural
language
value
(e.g.,
English,
French,
Chinese),
as
well
as
a
natural
base
writing
direction
(left-to-right
or
right-to-left).
The
infoset
has
entries
to
set
these
values,
which
can
influence,
for
example,
the
behavior
of
a
user
agent
(e.g.,
it
might
place
a
pop-up
for
a
table
of
contents
on
the
right
hand
side
for
publications
whose
natural
base
direction
is
right-to-left).
As
a
result,
the
infoset
has
entries
to
assign:
set:
the
natural
language
;
,
and
the
base
direction
(the
display
direction
for
the
property).
value)
Issue
220
:
Setting
of
both
the
(text)
direction
i18n-tracking
topic:internationalization
Web
Publication
and
the
natural
language
properties
values
of
the
topic:manifest
topic:metadata
infoset
topic:schema
mapping
This
is
a
completely
open
issue
at
this
moment,
both
for
JSON-LD
and
Schema.org...
The
only
(incomplete)
approach
would
be
to
rely
on,
and
base
everything,
on
the
UTF-encoding
of
the
text...
.
4.4.5.1
Infoset
Requirements
The
Web
Publication's
infoset
MAY
contain
global
language
and
the
base
direction
declarations.
declarations
for
the
Web
Publication.
The
natural
language
MUST
be
a
tag
that
conforms
to [
bcp47
],
while
the
base
language
direction
MUST
have
one
of
the
following
values:
ltr
:
left-to-right;
indicates
that
the
textual
values
are
explicitly
directionally
set
to
left-to-right
text;
rtl
:
right-to-left;
indicates
that
the
textual
values
are
explicitly
directionally
set
to
right-to-left
text;
auto
:
indicates
that
the
textual
values
are
explicitly
directionally
set
to
the
direction
of
the
first
character
with
a
strong
directionality.
When
specified,
these
properties
are
also
used
as
defaults
for
textual
values
in
the
infoset
,
but
they
MAY
be
overridden
by
individual
properties.
.
Note
These
features
make
it
possible
It
is
important
to
add
differentiate
the
title
language
of
a
publication
in
different
languages,
or
repeat
the
creators’
names
using
different
scripts.
User
agents
MUST
NOT
publication
use
from
the
language
and
the
base
direction
outside
the
context
of
the
infoset
(e.g.,
individual
resources
that
compose
it.
If
such
resources
are,
for
example,
in
HTML
,
the
processing
or
rendering
language
and
direction
need
to
be
set
in
those
resources,
too.
The
language
and
base
direction
of
the
publication
are
not
inherited.
The
global
language
information
MAY
be
overridden
by
individual
values.
When
using
Web
Publication
content).
These
manifests
with
bidirectional
text,
user
agents
SHOULD
identify
the
base
direction
of
any
given
natural
language
value
by
scanning
the
text
for
the
first
strong
directional
character.
Once
the
base
direction
has
been
identified,
user
agents
MUST
determine
the
appropriate
rendering
and
display
of
natural
language
values
do
not
override
similar
declarations
according
to
the
Unicode
Bidirectional
Algorithm [
bidi
].
This
could
require
wrapping
additional
control
characters
or
markup
around
the
string
prior
to
display,
in
any
resource,
nor
do
they
serve
as
global
defaults
when
such
information
order
to
apply
the
base
direction.
(See
C.
Examples
for
bidirectional
texts
.)
Issue
This
section,
in
particular
the
features
related
to
text
directions,
must
be
reviewed
by
I18N
experts.
If
the
manifest
is
not
provided
embedded
in
the
primary
entry
page
via
a
resource.
script
element,
and
the
manifest
does
not
set
the
global
language
and/or
the
base
direction
(see
4.4.5.2.1
Global
Language
and
Direction
),
the
lang
and
the
dir
attributes
of
the
script
element
are
used
as
the
global
language
and
base
direction
,
respectively
(see
the
details
on
handling
the
lang
and
dir
attributes
in [
html
]).
Issue
It
is
to
be
discussed
whether
this
last
paragraph,
i.e.,
inheriting
values
from
script
,
should
be
kept.
If
a
user
agent
requires
the
language
and
one
is
not
available
in
the
infoset
(globally
(globally,
or
specifically
for
a
that
property),
or
the
obtained
value
is
invalid,
has
been
specified,
the
user
agent
MAY
attempt
to
determine
the
language.
This
specification
does
not
mandate
how
such
a
language
tag
is
created.
The
user
agent
might:
use
the
non-empty
language
declaration
of
the
manifest;
use
the
first
non-empty
language
declaration
found
in
a
resource
in
the
default
reading
order
;
As
this
infoset
item
refers
to
several
aspects
of
setting
language
and
direction,
each
is
these
are
treated
separately.
4.4.5.2.1
Default
language
Global
Language
and
direction
Direction
The
default
language
and
base
direction
for
all
textual
information
in
the
manifest
MUST
be
set
by
extending
the
context
of
the
manifest
to
include
the
right
features.
To
set
the
language,
the
context
information
MUST
be
extended
by
the
@language
keyword
Term
Description
Required
Value
[
json-ld
schema.org
]:
{
: [
,
,
{
}
],
…
}
The
value
of
the
]
Mapping
topic:manifest
ltr
,
rtl
,
or
auto
topic:schema
mapping
(None)
Note
The
right
approach
is
If
authors
intend
to
extend
the
context
through
{
}
in
use
a
manifest,
or
a
manifest
template,
both
as
embedded
manifest
and
as
a
separate
resource,
they
are
strongly
encouraged
to
set
these
properties
explicitly
to
avoid
interference
of
the
(list
of)
containing
@context
.
Although
not
rejected
by
schema.org,
it
is
also
ignored.
script
element
in
case
of
embedding.
4.4.5.2.2
Item
specific
language
and
direction
Item-specific
Language
It
is
possible
to
set
the
language
and
base
direction
for
any
textual
value
in
the
manifest.
This
information
MUST
be
set
for
each
item
separately
using
the
@value
and
@language
keywords
[
(instead
of
a
simple
string) [
json-ld
]:
{
Example 15: Setting the default language of an author name to French
The
value
of
the
language
tag
MUST
be
set
to
a
language
code
as
defined
in
[
bcp47
].
If
not
set,
the
default
value
is
the
default
value
of
the
manifest
.
The
value
of
It
is
not
possible
to
set
the
base
direction
MUST
be
"
ltr
"
or
"
rtl
",
as
appropriate.
explicitly
for
a
value.
Issue
219
Note
:
Expressing
Setting
the
language
of
an
item,
say,
"name"
topic:internationalization
topic:manifest
topic:metadata
direction
for
a
natural
text
value
is
currently
not
possible
in
JSON
-LD [
topic:schema
mapping
json-ld
The
requirement
is
that
it
should
be
possible
to
express
].
In
case
the
language
of,
say,
JSON
-LD
community,
as
well
as
the
title
or
name
schema.org
community,
introduces
such
a
feature,
future
versions
of
this
specification
may
extend
the
author
individually.
This
does
not
seem
ability
of
Web
Publication
Manifests
to
work
in
Schema.org...
include
this.
4.4.6
Last
Modification
Date
The
last
modification
date
is
the
date
when
the
Web
Publication
was
last
updated
(i.e.,
whenever
changes
were
last
made
to
any
of
the
resources
of
the
Web
Publication,
including
the
manifest
).
4.4.6.1
Infoset
Requirements
The
last
modification
date
does
not
necessarily
reflect
all
changes
to
the
Web
Publication
(e.g.,
third-party
content
could
change
without
the
author
being
aware).
User
agents
SHOULD
check
the
last
modification
date
of
individual
resources
to
determine
if
they
have
changed
and
need
updating.
The
publication
date
is
the
date
on
which
the
Web
Publication
was
originally
published.
It
represents
a
static
event
in
the
lifecycle
of
a
Web
Publication
and
allows
subsequent
revisions
to
be
identified
and
compared.
4.4.7.1
Infoset
Requirements
The
exact
moment
of
publication
is
intentionally
left
open
to
interpretation:
it
could
be
when
the
Web
Publication
is
first
made
available
online
or
could
be
a
point
in
time
before
publication
when
the
Web
Publication
is
considered
final.
The
reading
progression
establishes
the
reading
direction
from
one
resource
to
the
next
within
a
Web
Publication
.
4.4.8.1
Infoset
Requirements
The
value
of
this
property
may
be:
ltr
:
left-to-right;
rtl
:
right-to-left;
auto
:
the
user
agent
chooses
the
direction.
The
default
value
is
auto
.
This
infoset
item
has
no
effect
on
the
rendering
of
the
individual
primary
resources;
it
is
only
relevant
for
the
progression
direction
from
one
resource
to
the
other.
Note
The
reading
progression
of
a
Web
Publication
is
used
to
adapt
such
publication
level
interactions
as
menu
position,
swap
direction,
defining
tap
zones
to
lead
the
user
to
the
next
and
previous
pages,
touch
gestures,
etc.
Relying
on
the
title
element
could
be
semantically
problematic
if
the
Web
Publication
consists
of
several
HTML
resources
(e.g.,
one
per
chapter
of
a
book),
because
the
HTML
definition
defines
this
element
as
"metadata"
for
the
enclosing
HTML
document,
not
for
a
collection
of
resources.
Using
this
element
is,
on
the
other
hand,
preferred
in
the
case
of
a
publication
consisting
of
a
single
HTML
document
(e.g.,
a
scholarly
journal
article).
If
a
user
agent
requires
a
title
and
one
is
not
available
in
the
infoset
,
it
MAY
create
one
(e.g.,
provide
a
language-specific
placeholder
title
or
use
the
URL
of
the
manifest).
Note
A
user
agent
is
not
expected
to
produce
a
meaningful
title
[
wcag20
]
for
a
Web
Publication
when
one
is
not
specified.
An
accessibility
report
provides
information
about
the
suitability
of
a
Web
Publication
for
consumption
by
users
with
varying
preferred
reading
modalities.
These
reports
typically
identify
the
result
of
an
evaluation
against
established
accessibility
criteria,
such
as
those
provided
in
[
WCAG21
],
and
are
an
important
source
of
information
in
determining
the
usability
of
a
Web
Publication.
4.5.1.1
Infoset
Requirements
The
infoset
SHOULD
include
a
link
to
an
accessibility
report
when
one
is
available
for
a
Web
Publication.
It
is
RECOMMENDED
that
the
report
be
included
as
a
resource
of
the
Web
Publication.
It
is
also
RECOMMENDED
that
the
accessibility
report
be
provided
in
a
human-readable
format,
such
as
HTML
[
html
].
Augmenting
these
reports
with
machine-processable
metadata,
such
as
provided
in
Schema.org
[
schema.org
],
is
also
RECOMMENDED
.
Editor's
note
Machine-readable
accessibility
metadata
may
be
recommended
in
whatever
format
is
used
to
externalize
publication
metadata
(e.g.,
to
ensure
availability
for
search).
Depending
how
this
externalizing
is
done,
adding
machine-processable
accessibility
metadata
to
such
a
record
could
take
precedence
over,
or
complement,
the
accessibility
record.
4.5.1.2
Manifest
Expression
If
present
in
the
manifest,
the
accessibility
report
MUST
be
expressed
as
a
PublicationLink
.
The
rel
value
of
the
PublicationLink
MUST
include
the
https://www.w3.org/ns/wp#accessibility-report
identifier.
Editor's
note
The
Working
Group
will
attempt
to
define
the
accessibility-report
term
by
IANA,
to
avoid
using
a
URL
.
Users
often
have
the
legal
right
to
know
and
control
what
information
is
collected
about
them,
how
such
information
is
stored
and
for
how
long,
whether
it
is
personally
identifiable,
and
how
it
can
be
expunged.
Including
a
statement
that
addresses
such
privacy
concerns
is
consequently
an
important
part
of
publishing
Web
Publications
.
Even
if
no
information
is
collected,
such
a
declaration
increases
the
trust
users
have
in
the
content.
4.5.2.1
Infoset
Requirements
A
link
to
a
privacy
policy
can
be
included
in
the
infoset
.
It
is
RECOMMENDED
that
the
privacy
policy
be
included
as
a
resource
of
the
Web
Publication.
It
is
RECOMMENDED
that
the
privacy
policy
be
provided
in
a
human-readable
format,
such
as
HTML
[
html
].
Refer
to
9.
Privacy
for
more
information
about
privacy
considerations
in
Web
Publications.
https://w3c.github.io/wpub/#wp-privacy
needs
more
clarity,
and
not
be
so
general.
Most
of
the
privacy
policy
collection
and
enforcement
is
upstream
from
the
document
markup,
except
where
the
markup
explicitly
collects
data.
The
cover
is
an
image
that
user
agents
can
use
to
present
the
Web
Publication
to
users
(e.g.,
in
a
library
or
bookshelf,
or
when
initially
loading
the
Web
Publication).
4.6.1.1
Infoset
Requirements
The
infoset
SHOULD
include
a
reference
to
a
cover
image.
User
agents
SHOULD
NOT
use
the
cover
image
as
the
sole
means
of
selecting
or
accessing
Web
Publications.
A
user
agent
SHOULD
use
the
Web
Publication's
title
and
creators
as
text
alternatives
for
such
interfaces.
More
than
one
cover
image
MAY
be
referenced
from
the
infoset
to
provide
alternative
sizes
and
resolutions
for
different
device
screens.
A
user
agent
MAY
create
a
cover
for
a
Web
Publication
if
one
is
not
present.
This
specification
does
not
define
requirements
for
the
creation
of
such
cover
images
(e.g.,
the
user
agent
could
use
a
placeholder
image,
generate
an
image
dynamically,
or
incorporate
properties
of
the
infoset
into
a
graphic,
such
as
the
title
or
creators).
4.6.1.2
Manifest
Expression
If
present
in
the
manifest,
the
cover
MUST
be
expressed
as
a
PublicationLink
.
The
URL
expressed
in
the
url
term
MUST
NOT
include
a
fragment
identifier.
The
rel
value
of
the
PublicationLink
MUST
include
the
https://www.w3.org/ns/wp#cover-page
identifier.
Note
The
Working
Group
will
attempt
to
define
the
cover-page
term
by
IANA,
to
avoid
using
a
URL
.
If
neither
of
the
above
cases
results
in
a
link
to
the
table
of
contents,
the
Web
Publication
does
not
have
a
table
of
contents
and
this
property
MUST
NOT
be
included
in
the
infoset
.
If
the
table
of
contents
resource
contains
more
than
one
element
identified
by
the
role
"
doc-toc
",
user
agents
MUST
use
the
first
element
in
document
order
as
the
table
of
contents.
4.6.2.2
Manifest
Expression
If
present
in
the
manifest,
the
table
of
content
MUST
be
expressed
as
a
PublicationLink
.
The
URL
expressed
in
the
url
term
MUST
NOT
include
a
fragment
identifier.
Note
that
a
particular
resource's
URL
MUST
NOT
appear
in
more
than
one
of
these
lists,
and
a
URL
MUST
NOT
be
repeated
within
a
list.
4.7.1
Default
Reading
Order
The
default
reading
order
is
a
specific
progression
through
a
set
of
Web
Publication
resources.
A
user
might
follow
alternative
pathways
through
the
content,
but
in
the
absence
of
such
interaction
the
default
reading
order
defines
the
expected
progression
from
one
resource
to
the
next.
4.7.1.1
Infoset
Requirements
The
default
reading
order
MUST
include
at
least
one
resource.
The
default
reading
order
is
specified
directly
in
the
manifest.
However,
if
the
reading
order
consists
of
only
a
single
resource,
namely
the
primary
entry
page
of
the
Web
Publication,
the
default
reading
order
need
not
be
specified.
4.7.1.2
Manifest
Expression
If
present
in
the
Web
Publication
Manifest,
this
item
MUST
be
mapped
on
the
readingOrder
term,
defined
specifically
for
Web
Publications.
The
union
of
the
resource
list
and
default
reading
order
represents
the
definitive
list
of
resources
that
belong
to
the
Web
Publication.
All
other
resources
are
external
to
the
Web
Publication.
4.7.2.1
Infoset
Requirements
The
completeness
of
the
resource
list
will
affect
the
usability
of
the
Web
Publication
in
certain
reading
scenarios
(e.g.,
the
ability
to
read
the
Web
Publication
offline).
For
this
reason,
it
is
strongly
RECOMMENDED
to
provide
a
comprehensive
list
of
all
of
the
Web
Publication's
constituent
resources
beyond
those
listed
in
the
default
reading
order
.
In
some
cases,
a
comprehensive
list
of
these
resources
might
not
be
easily
achieved
(e.g.,
third-party
scripts
that
reference
resources
from
deep
within
their
source),
but
a
user
agent
SHOULD
still
be
able
to
render
a
Web
Publication
even
if
some
of
these
resources
are
not
identified
as
belonging
to
the
Web
Publication
(e.g.,
when
it
is
taken
offline
without
them).
Editor's
note
The
previous
version
of
the
draft
included:
If
a
user
agent
encounters
a
resource
that
it
cannot
locate
in
the
resource
list,
it
MUST
treat
the
resource
as
external
to
the
Web
Publication
(e.g.,
it
might
alert
the
user
before
loading,
open
the
resource
in
a
new
window,
or
unload
the
current
Web
Publication
and
resume
normal
Web
browsing).
This
was
not
decided
on
the
Toronto
F2F,
and
is
still
open.
4.7.2.2
Manifest
Expression
If
present
in
the
Web
Publication
Manifest,
this
item
MUST
be
mapped
on
the
resources
term,
defined
specifically
for
Web
Publications.
The
links
property
enumerates
resources
that
are
significant
to
a
Web
Publication
but
are
not
essential
to
the
processing
and
rendering
of
it
(i.e.,
the
content
of
the
Web
Publication
remains
readable
even
if
the
resources
are
not
available).
Examples
of
linked
resources
might
include:
a
privacy
policy
or
license
that
a
user
agent
might
offer
a
link
to
from
a
shelf;
a
metadata
record
that
user
agents
could
use
to
discover
and
display
more
information
about
the
Web
Publication;
a
dictionary
of
terms
a
user
agent
could
process
to
provide
enhanced
language
help;
large
fonts
files
that
enhance
the
appearance
of
the
Web
Publication
but
are
not
vital
to
its
rendering;
third-party
scripts
that
are
not
intended
for
use
when
a
Web
Publication
is
taken
offline
or
packaged
(e.g.
tracking
scripts).
4.7.3.1
Infoset
Requirements
The
completeness
of
the
links
list
might
affect
the
usability
of
the
Web
Publication
in
certain
scenarios
(e.g.,
a
user
agent
might
chose
to
omit
these
resources
when
taking
a
publication
offline,
or
they
could
be
omitted
when
packaged
version
of
the
Web
Publication
is
created).
For
this
reason,
it
is
strongly
RECOMMENDED
to
provide
a
comprehensive
list
of
all
of
the
Web
Publication's
non-critical
resources.
The
links
list
SHOULD
include
resources
necessary
to
render
a
linked
resource
(e.g.,
scripts,
images,
style
sheets).
The
infoset
is
designed
to
provide
a
basic
set
of
properties
for
use
by
user
agents
in
presenting
and
rendering
a
Web
Publication
,
but
MAY
be
extended
in
the
following
ways:
Although
both
methods
are
valid,
the
use
of
linked
records
to
extend
the
infoset
is
RECOMMENDED
.
This
specification
does
not
define
how
such
additional
properties
are
compiled,
stored
or
exposed
by
user
agents
in
their
internal
representation
of
the
infoset
.
A
user
agent
MAY
ignore
some
or
all
extended
properties.
4.8.1
Linked
records
Extending
the
manifest
through
links
to
a
record,
such
as
an
ONIX [
onix
]
or
BibTeX [
bibtex
]
file,
MUST
be
expressed
using
a
PublicationLink
object,
where:
the
rel
value
of
the
PublicationLink
SHOULD
include
a
relevant
identifier
defined
by
IANA
or
by
other
organizations;
if
the
link
record
contains
descriptive
metadata
it
MUST
include
the
describedby
(IANA)
identifier;
the
value
of
the
encodingFormat
in
the
link
MUST
use
the
MIME
media
type [
rfc2046
]
defined
for
that
particular
type
of
record,
if
applicable.
Linked
records
MUST
be
included
in
the
resource
list
when
they
are
part
of
the
Web
Publication
(i.e.,
are
needed
for
more
than
just
infoset
extensibility).
Otherwise,
they
MUST
be
included
in
the
links
list
.
{
Example 28: Link to external ONIX for Books Metadata file
The
application/onix+xml
MIME
type
has
not
yet
been
registered
by
IANA
at
the
time
of
writing
this
document,
and
is
included
in
the
example
for
illustrative
purposes
only.
4.8.2
Additional
Properties
in
the
Manifest
Additional
properties
can
be
included
directly
in
the
manifest.
It
is
RECOMMENDED
that
these
properties
be
taken
from
public
schemes
like
[
schema.org
]
or
[
dcterms
]
and
use
values
from
controlled
vocabularies
whenever
possible.
Proprietary
terms
MAY
be
used,
but
it
is
RECOMMENDED
that
such
terms
be
included
using
Compact
IRIs
[
json-ld
],
with
prefixes
defined
as
part
of
the
context.
{
Example 29: Usage of the schema.org 'copyrightYear' and 'copyrightHolder' terms, as an extension to the basic data
A
prefix
definition
dc
for
[
dcterms
]
is
included
in
the
context
file
of
[
schema.org
].
This
means
that
it
is
not
necessary
to
add
the
prefix
explicitly.
The
same
is
true
for
a
number
of
other
public
vocabularies;
see
the
schema.org
context
file
for
further
details.
5.
Web
Publication
Lifecycle
Editor's
note
The
publishing
working
group
is
currently
evaluating
the
best
approach
for
implementing
Web
Publications
in
user
agents.
This
note
is
intended
to
provide
an
overview
of
where
current
thinking
is
at
and
what
issues
are
under
consideration.
The
development
of
Web
Publications
is
not
viewed
as
a
separate
forking
of
the
Web,
but
an
enhancement
layer
that
can
be
supported
by
user
agents.
To
that
end,
the
primary
constraints
on
any
solution
for
Web
Publications
are
that:
the
rendering
of
Web
Publications
must
not
interfere
with
the
underlying
Web
model
and
APIs
—
all
functionality
and
enhancements
must
be
layered
on
top;
a
Web
Publication
should
not
have
to
carry
its
own
implementation
code
—
functionality
is
ideally
provided
by
the
user
agent
and/or
polyfill.
While
this
specification
will
provide
implementation
flexibility
for
user
agents,
there
are
still
a
number
of
areas
that
have
been
identified
as
potentially
needing
to
be
detailed.
These
include:
initialization
expectations
for
a
Web
Publication:
automatic
initiation
v.
user
prompts;
linked
v.
directly
loaded
manifests;
resources
that
belong
to
more
than
one
Web
Publication.
the
creation
of
a
"publication
state":
persistence
of
publication
information
across
page
loads;
location
and
persistence
of
UI;
indications
of
supported
features;
DOM
issues
such
as
persistence
of
numbering
schemes.
The
working
group
intends
to
flesh
out
the
lifecycle
in
later
revisions
once
it
is
clearer
what
models
are
viable
and
what
solutions
can
be
standardized.
Input
on
the
feasibility
and
challenges
of
these
approaches
is
welcome
at
any
time.
5.1
Obtaining
a
manifest
The
steps
for
obtaining
a
manifest
are
given
by
the
following
algorithm.
The
algorithm,
if
successful,
returns
a
processed
manifest
and
the
manifest
URL
;
otherwise,
it
terminates
prematurely
and
returns
nothing.
In
the
case
of
nothing
being
returned,
the
user
agent
MUST
ignore
the
manifest
declaration.
From
the
Document
of
the
top-level
browsing
context,
let
origin
be
the
Document
's
origin,
and
manifest
link
be
the
first
link
element
in
tree
order
whose
rel
attribute
contains
the
token
publication
.
If
origin
is
an
[
html
]
opaque
origin,
terminate
this
algorithm.
If
manifest
link
is
null
,
terminate
this
algorithm.
If
manifest
link
's
href
attribute's
value
is
the
empty
string,
then
abort
these
steps.
Let
manifest
URL
be
the
result
of
parsing
the
value
of
the
href
attribute,
relative
to
the
element's
base
URL
.
If
parsing
fails,
then
abort
these
steps.
Let
request
be
a
new
[
fetch
]
request,
whose
URL
is
manifest
URL
,
and
whose
context
is
the
same
as
the
browsing
context
of
the
Document
.
If
the
manifest
link
's
crossOrigin
attribute's
value
is
'
use-credentials
',
then
set
request
's
credentials
to
'
include
'.
Await
the
result
of
performing
a
fetch
with
request
,
letting
response
be
the
result.
If
response
is
a
network
error,
terminate
this
algorithm.
Let
text
be
the
result
of
UTF-8
decoding
response
's
body
.
Let
manifest
be
the
result
of
running
processing
a
manifest
given
text
,
manifest
URL
,
and
the
URL
that
represents
the
address
of
the
top-level
browsing
context.
This
section
will
require
additional
work
if
we
also
decide
to
allow
JSON
-LD
embedded
in
HTML
.
5.2
Processing
the
manifest
The
steps
for
processing
a
manifest
are
given
by
the
following
algorithm.
The
algorithm
takes
a
text
string
as
an
argument,
which
represents
a
manifest
,
and
a
manifest
URL
[
url
],
which
represents
the
location
of
the
manifest,
and
a
document
URL
[
url
].
The
output
from
inputting
a
JSON
document
into
this
algorithm
is
a
processed
manifest
.
The
new
JSON
-LD
based
approach
will
require
additional
processing
from
the
client.
Due
to
the
flexible
nature
of
JSON
-LD
and
schema.org,
a
simple
conversion
from
JSON
to
WebIDL
won't
be
enough.
6.
User
Agent
Features
Editor's
note
This
section
contains
placeholders
for
possible
reading
enhancements/features
the
user
agent
may/should/must
provide.
The
list
is
subject
to
addition,
modification
and
removal
as
the
enhancements
get
discussed
in
more
detail.
Before
starting
a
discussion
on
the
individual
affordances'
issues
,
the
WG
should
have
a
consensus
on
what
exactly
is
to
be
defined
for
each
of
those.
it
MUST
inform
the
user
that
the
current
resource
is
part
of
a
Web
Publication
it
SHOULD
display
the
title
of
the
Web
Publication
it
MAY
display
additional
metadata
from
the
infoset
Publication
mode
is
a
display
mode
implemented
by
the
user
agent
that
follows
the
conventions
listed
in
presentation
and
navigation
.
6.2
Presentation
6.2.1
Layout
The
layout
and
rendering
of
Web
Publications
is
governed
by
the
same
rules
that
apply
to
all
Web
content:
HTML
documents
are
styled
and
laid
out
according
to
the
rules
of
CSS
,
SVG
documents
are
rendered
as
defined
by
that
format,
etc.
This
specification
requires
no
particular
profile
or
subset
of
CSS
,
HTML
,
or
SVG
to
be
supported,
other
than
the
expectations
set
for
these
technologies
by
their
respective
specifications.
Editor's
note
This
specification
intentionally
avoids
introducing
any
new
layout
features.
Any
shortcoming
of
the
Web
platform
in
terms
of
layout
needs
to
be
addressed
for
the
whole
Web
platform,
which
means
via
CSS
.
This
working
group
will
work
with
other
relevant
groups
of
the
W3C
to
address
platform-wide
limitations
that
negatively
impact
Web
Publications
.
For
the
purposes
of
layout,
each
resource
of
a
Web
Publication
is
treated
as
a
separate
document.
User
agents
MUST
NOT
mix
content
from
multiple
resources
in
the
same
rendering
(e.g.,
CSS
floats
or
absolutely
positioned
elements
from
one
resource
cannot
intrude
or
overlap
with
content
from
an
other
resource).
Note
Despite
this
general
requirement
that
each
resource
should
be
treated
as
a
separate
document
for
the
purpose
of
layout,
there
are
some
places
where
CSS
specifications
should
be
amended
to
be
able
to
deal
more
intelligently
with
collections
of
resources
like
Web
Publications
.
One
instance
is
the
definition
of
cross-references
,
which
are
currently
restricted
to
work
only
within
a
single
document.
This
restriction
should
be
relaxed
to
allow
for
cross-references
between
separate
resources
of
a
single
Web
Publication.
Another
related
would
be
to
allow
counters
to
accumulate
across
multiple
resources
of
a
single
Web
Publication
(e.g.,
so
that
figures
in
multiple
sections
may
be
numbered
in
a
single
sequence).
6.2.2
User
Settings
When
a
user
agent
renders
a
Web
Publication
,
it
SHOULD
provide
user
settings
to
customize
the
experience.
User
settings
MAY
include:
text
size;
font
family;
display
mode
(night,
high
contrast,
etc.);
playback
speed
(for
audio
and
video
resources).
This
specification
does
not
cover
how
user
agents
override
author
styles
to
offer
user
settings.
Editor's
note
To
provide
user
settings
in
their
reader
mode,
browsers
usually
get
rid
of
most
of
the
author
styles.
There
is
always
a
tension
in
reading
environments
between
author
styles
and
the
user's
preference,
which
is
very
hard
to
balance.
Publications
have
historically
been
presented
via
paged
media,
whereas
Web
pages
almost
always
scroll.
As
the
preferences
of
individual
readers
vary,
and
as
different
types
of
publications
are
better
suited
for
one
or
the
other,
this
specification
encourages
user
agents
to
support
both,
and
to
offer
a
choice
to
their
users.
Editor's
note
It
might
be
useful
for
authors
to
be
able
to
specify
a
preference
between
scrolling
and
pagination,
even
if
a
strict
requirement
is
not
possible.
This
should
most
likely
be
addressed
through
an
extension
of
@viewport
or
of
the
viewport
meta
tag
(see [
css-device-adapt
]),
or
possibly
through
an
extension
of
@page
(see [
css-page-3
]).
This
should
be
discussed
with
the
relevant
working
groups
(
CSSWG
,
WebPlatformWG
,
WHATWG
).
When
a
user
agent
renders
a
Web
Publication
in
a
paginated
layout,
it
MUST
lay
out
each
document
in
the
default
reading
order
sequentially,
with
the
last
page
of
a
resource
being
followed
by
the
first
page
of
the
subsequent
one.
Editor's
note
To
avoid
blank
pages,
if
a
resource
ends
on
a
left
page
(resp.
right
page),
the
subsequent
one
should
start
on
a
right
page
(resp.
left
page)
even
if
the
page
progression
(see [
css-page-3
])
would
otherwise
lead
to
it
starting
on
the
opposite
page.
It
should
also
be
possible
to
use
the
break-before
property
(see [
css-break-3
])
to
force
the
content
to
resume
on
the
opposite
side
if
that
was
desired
by
the
author.
[
css-page-3
]
needs
to
be
amended
to
describe
this
exception
to
the
general
behavior
when
dealing
with
collections
of
documents
instead
of
individual
documents.
Editor's
note
How
is
pagination
supposed
to
work
when
subsequent
resources
have
opposite
page
progression
directions
(see [
css-page-3
]).
For
example,
due
to
different
a
different
writing
mode?
This
is
not
necessarily
a
problem
from
a
layout
point
of
view,
as
each
page
is
independent,
but
from
an
UI
point
of
view.
If
swiping
left
means
next
page
until
the
end
of
one
chapter,
and
starts
meaning
previous
page
in
the
next
chapter
because
the
language
is
switched
from
English
to
Hebrew,
this
is
going
to
be
confusing.
Editor's
note
[
css-page-3
]
needs
to
be
amended
so
that
page
counters
are
not
automatically
reset
to
at
the
beginning
of
each
new
resource
belonging
to
the
same
Web
Publication.
Hyperlinks
are
the
means
by
which
multiple
resources
are
linked
together
on
the
Web.
When
users
reach
the
end
of
one
resource,
they
have
to
activate
a
hyperlink
to
move
to
the
next
resource
in
the
sequence.
While
this
model
of
navigation
is
effective,
it
is
also
disruptive
for
immersive
reading
—
it
forces
users
to
disengage
from
the
content
and
perform
the
actions
necessary
to
activate
the
links.
It
is
also
limited
to
media
types
that
support
hyperlinks.
The
default
reading
order
provides
an
enhancement
to
the
hyperlink
model,
allowing
the
user
agent
to
automatically
move
the
user
to
the
next
resource
when
a
more
natural
action
occurs,
like
a
swipe
across
the
screen.
It
is
similar
conceptually
and
functionally
to
the
link
element's
next
and
prev
relationships
[
html
].
User
agents
SHOULD
provide
the
option
to
save
this
progression
in
the
publication
and
returns
the
user
to
their
last
location
the
next
time
they
open
the
publication.
When
the
user
agent
obtains
a
manifest
for
the
first
time,
it
MAY
also
prompt
the
user
whether
they
would
like
to:
continue
reading
the
publication
from
their
current
location;
or
User
agents
should
provide
an
affordance
that
saves
the
reading
progression
in
the
publication
and
return
the
user
to
that
location
the
next
time
that
she
opens
the
publication
again.
“There
should
be
a
means
to
indicate
the
author’s
preferred
navigation
structure
among
the
resources
of
a
Web
Publication.
A
user
agent
needs
to
know
the
sequence
in
which
to
present
components
of
a
Web
Publication
to
the
user,
including
the
starting
point.”
(See
[
pwp-ucr
])
User
agents
should
provide
an
affordance
that
saves
the
reading
progression
in
the
publication
and
return
the
user
to
that
location
the
next
time
that
she
opens
the
publication
again.
6.6.1
Short
description
The
user
must
be
able
to
leave
the
Web
Publication
and
return
to
it
at
the
last
position
they
left
from.
The
User
Agent
must
retain
the
reading
position,
based
on
the
last
known
position
of
the
reader
in
the
web
publication.
The
position
should
be
based
on
the
reader's
position
in
the
file,
within
the
reading
order.
The
user
agent
may
retain
reading
state
if
the
web
publication
is
revised.
6.6.2
Affordances
The
navigation
of
the
web
publication
should
be
defined
in
the
Default
Reading
Order
required
by
the
Information
Set.
User
Agents
should
not
have
to
set
the
reading
state
in
the
following
type
of
resources:
External
Links
(i.e.
a
link
to
google.com)
Data
references
(i.e.
a
linked
CSV
file)
Multimedia
content
(i.e.
a
video)
Reading
state
should
only
apply
to
content
documents
listed
as
being
within
the
bounds
of
the
Web
Publication.
6.6.3
Examples
Example
1:
Sarah
is
reading
a
long
article
on
her
way
to
work.
She
arrives
before
she
has
finished,
but
wants
to
continue
from
the
place
she
left
off.
The
user
agent
should
remember
her
reading
state
for
the
next
time
she
opens
the
publication.
Testing
If
a
tester
opens
a
web
publication
in
a
WP-aware
UA,
moves
ahead
in
the
publication,
closes
the
reader,
then
reopens
it,
they
should
be
returned
to
the
last
known
reading
state.
7.
Web
Publication
Locators
This
section
is
non-normative.
Editor's
note
The
document
referred
from
this
section,
i.e.,
Web
Annotation
Extensions
for
Web
Publications [
wpub-ann
],
has
been
recently
renamed.
Its
previous
was
"Locators
for
Web
Publication".
The
terminology
used
in
this
section
has
to
be
realigned
with
the
name
change.
Locators
are
used
to
identify,
locate,
retrieve,
and/or
reference
locations
and
content
fragments
within
Web
Publications
(e.g.,
for
address(es),
bookmarks,
and
annotations).
Locators
traditionally
take
the
form
of
fragment
identifiers [
rfc3986
],
where
the
portion
of
a
URL
preceded
by
a
number
sign
character
(
#
)
identifies
a
specific
position
within
the
referenced
resource.
For
some
use
cases,
it
is
essential
to
identify
and
reference
a
Web
Publication
resource—or
a
location
in
or
a
segment
of
a
resource—in
the
scope
or
context
of
the
Web
Publication
to
which
it
belongs.
A
traditional
fragment
identifier
cannot
satisfy
this
requirement,
since
only
the
URL
of
the
constituent
resource
containing
the
location
or
content
fragment
of
interest
is
expressed.
The
Web
Annotation
Extensions
for
Web
Publications [
wpub-ann
]
document,
based
on
the
Web
Annotation
Model [
annotation-model
],
addresses
this
issue
by
providing
the
means
to
express
both
the
URL
of
the
resource
and
the
URL
of
the
Web
Publication.
Web
Publication
Locators
also
address
the
problem
of
referencing
into
a
resource
that
was
not
authored
with
such
a
need
in
mind.
A
fragment
identifier
can
only
reference
elements
with
explicit
identifiers
and
locations
with
explicit
anchor
points.
Web
Publication
Locators
include
a
variety
of
selectors
that
work
with
the
general
structures
and
content
of
a
resource
(e.g.,
text
selectors,
CSS
selectors).
Editor's
note
As
Web
Publication
Locators
currently
rely
on
a
JSON
-based
expression
syntax,
it
is
not
yet
clear
how
much
of
this
syntax
can
be
translated
to
a
fragment
identifier.
This
may
limit
the
usefulness
beyond
expressions
that
are
also
JSON
-based
(e.g.,
outside
of
annotations
or
bookmarks).
Editor's
note
Illustrate
with
example
of
an
easy
to
understand
Web
Publication
Locator,
such
as
might
be
used
in
annotating
a
simple
Web
Publication.
The
semantics
of
Web
Publication
Locators
are
a
mapping
and
extension
of
the
Web
Annotation
Data
Model [
annotation-model
]
and
Vocabulary [
annotation-vocab
]
for
describing
and
referencing
a
segment
of
a
Web
resource.
As
a
result,
Web
Publication
Locators
provide
the
expressiveness
needed
for
a
broad
range
of
annotation
and
bookmarking
use
cases.
Additionally,
Web
Publication
Locators
provide
a
way
to
identify
and
reference
a
location
within
a
Web
Publication
(i.e.,
as
distinct
from
identifying
and
referencing
a
content
fragment
consisting
of
a
span
of
characters
or
bytes).
A
Web
Publication
Locator
can
be
used
to
identify,
retrieve
and/or
reference
a
fragment
of
a
Web
Publication
that
spans
multiple
resources.
Note
In
composing
a
Web
Publication
Locator,
use
the
canonical
identifier
of
the
Web
Publication
in
preference
to
any
alternative
addresses.
Such
use
facilitates
the
collation
of
Web
Publication
Locators
associated
with
a
particular
Web
Publication.
URLs
of
Web
Publication
resources
appearing
in
a
Web
Publication
Locator
should
match
the
URL
of
the
resource
provided
in
the
infoset
.
8.
Security
Editor's
note
Placeholder
for
security
issues.
9.
Privacy
Editor's
note
Placeholder
for
privacy
issues.
A.
WebIDL
A.1
Introduction
This
section
is
non-normative.
Although
a
Web
Publication
manifest
is
authored
as
[
json-ld
],
user
agents
process
this
information
into
an
internal
data
structure
representing
the
infoset
in
order
to
utilize
the
properties.
The
exact
manner
in
which
this
processing
occurs,
and
how
the
data
is
used
internally,
is
user
agent-dependent.
To
ensure
interoperability
when
exposing
the
infoset
items,
however,
this
appendix
defines
a
common,
abstract
representation
of
the
data
structures
using
the
standard
formalism
of
the
Web
Interface
Definition
Language
[
webidl-1
]
which
can
express
the
expected
names,
datatypes,
and
possible
restrictions
for
each
member
of
the
infoset
.
(A
WebIDL
representation
can
be
mapped
onto
ECMAScript,
C,
or
other
programming
languages.)
The
current
infoset
for
creators
is
not
fully
defined;
this
dictionary
might
be
further
improved
once
there
is
agreement
on
how
they
should
be
handled.
The
author
member
is
a
sequence
of
Contributor
dictionaries
where
each
dictionary
has
the
following
members:
name
Contains
one
or
more
localizable
string
for
the
contributor's
name.
id
Contains
a
canonical
identifier
for
the
contributor.
A.4
LocalizableString
dictionary
Editor's
note
This
definition
includes
a
slightly
tweaked
version
of
the
i18n
recommendation
that
also
includes
a
string
value
in
addition
to
a
language
and
a
direction.
A
simplified
diagram
of
the
structure
of
a
Web
Publication
.
The
Web
Publication
is
broken
down
into
two
elements.
The
first
element
is
the
actual
contents
(all
the
real
things
listed
in
the
manifest).
This
element
is
broken
down
into
the
CSS
,
the
actual
“things”
such
as
the
HTML
documents,
audio,
etc,
and
the
images,
fonts
etc.
The
actual
“things”
have
an
additional
subset
of
items
that
includes
the
entry
page
to
the
publication
and
all
of
the
other
documents.
The
second
element
is
the
Manifest
(
JSON
).
The
manifest
is
used
to
generate
the
Information
Set
(“Infoset”)
,
which
consists
of
a
list
of
all
the
“things”
in
the
publication,
the
publication
metadata,
and
the
default
reading
order
of
content.
It
is
noted
in
the
diagram
that
the
entry
page
has
to
link
to
the
manifest.
(
Return
to
the
diagram
of
Web
Publication.)
E.
F.
Acknowledgements
This
section
is
non-normative.
The
following
people
contributed
to
the
development
of
this
specification:
Greg
Albers
(J.
Paul
Getty
Trust)
Boris
Anthony
(The
Rebus
Foundation)
Christopher
Auclair
(VitalSource
|
Ingram
Content
Group)
Luc
Audrain
(Hachette
Livre)
Mike
Baker
(Houghton
Mifflin
Harcourt
(HMH))
Baldur
Bjarnason
(The
Rebus
Foundation)
Nick
Brown
(VitalSource
|
Ingram
Content
Group)
Jeff
Buehler
(Metrodigi,
Inc.)
Fred
Chasen
(
W3C
Invited
Experts)
Timothy
Cole
(University
of
Illinois
at
Urbana-Champaign)
Rachel
Comerford
(Macmillan
Higher
Education)
Garth
Conboy
(Google,
Inc.)
Christopher
Cosner
(Stanford
University)
Dave
Cramer
(Hachette
Livre)
Romain
Deltour
(DAISY
Consortium)
Marisa
DeMeglio
(DAISY
Consortium)
Vagner
Diniz
(NIC.br
-
Brazilian
Network
Information
Center)
Brady
Duga
(Google,
Inc.)
Ben
Dugas
(Rakuten,Inc.)
Roger
Espinosa
(University
of
Michigan
Library)
Reinaldo
Ferraz
(NIC.br
-
Brazilian
Network
Information
Center)
Heather
Flanagan
(RFC
Editor)
Jun
Gamo
(Voyager
Japan,
Inc.)
Hadrien
Gardeur
(Feedbooks)
Matt
Garrish
(DAISY
Consortium)
Harriett
Green
(University
of
Illinois
at
Urbana-Champaign)
Markku
Hakkinen
(Educational
Testing
Service)
Katie
Haritos-Shea
(Knowbility,
Inc)
Ivan
Herman
(
W3C
Staff)
Leslie
Hulse
(HarperCollins
Publishers)
Rick
Johnson
(VitalSource
|
Ingram
Content
Group)
Takeshi
Kanai
(Sony
Corporation)
Deborah
Kaplan
(
W3C
Invited
Experts)
Bill
Kasdorf
(Book
Industry
Study
Group)
George
Kerscher
(DAISY
Consortium)
Yuri
Khramov
(Evident
Point
Software
Corp.)
Toshiaki
Koike
(Voyager
Japan,
Inc.)
Peter
Krautzberger
(krautzource
UG)
Matt
Kuznicki
(Datalogics,
Inc.)
Charles
LaPierre
(Benetech)
Laurent
Le
Meur
(EDRLab)
Vladimir
Levantovsky
(Monotype)
Mia
Lipner
(Pearson
plc)
Edwina
Lui
(Kaplan
Publishing)
Phil
Madans
(Hachette
Livre)
Christopher
Maden
(University
of
Illinois
at
Urbana-Champaign)
Jia
Ma
(Kaplan
Publishing)
Liisa
McCloy-Kelley
(Penguin
Random
House)
Bill
McCoy
(
W3C
Staff)
Jonathan
McGlone
(University
of
Michigan
Library)
Hugh
McGuire
(The
Rebus
Foundation)
Nellie
McKesson
(
W3C
Invited
Experts)
Maureen
McMahon
(Kaplan
Publishing)
Selma
Morais
(NIC.br
-
Brazilian
Network
Information
Center)
Jasmine
Mulliken
(Stanford
University)
Shinyu
Murakami
(Vivliostyle
Inc.)
Makoto
Murata
(Vivliostyle
Inc.)
Cristina
Mussinelli
(Associazione
Italiana
Editori)
Christos
Nikolakakos
(Wiley)
Evan
Owens
(Cenveo
Publisher
Services)
Gregorio
Pellegrino
(Associazione
Italiana
Editori)
Fernando
Pinto
da
Silva
(EDRLab)
Chris
Powell
(University
of
Michigan
Library)
Jeff
Printy
(Macmillan
Higher
Education)
Ryan
Pugatch
(Hachette
Livre)
Joshua
Pyle
(Wiley)
Wendy
Reid
(Rakuten,Inc.)
Florian
Rivoal
(
W3C
Invited
Experts)
Leonard
Rosenthol
(Adobe
Systems
Inc.)
Nicholas
Ruffilo
(VitalSource
|
Ingram
Content
Group)
Robert
Sanderson
(J.
Paul
Getty
Trust)
Wolfgang
Schindler
(PONS
GmbH)
Jodi
Schneider
(University
of
Illinois
at
Urbana-Champaign)
Ben
Schroeter
(Pearson
plc)
Tzviya
Siegman
(Wiley)
Avneesh
Singh
(DAISY
Consortium)
Susanna
Skinner
(HarperCollins
Publishers)
Kathryn
Stewart
(Metrodigi,
Inc.)
David
Stroup
(Pearson
plc)
Lillian
Sullam
(Penguin
Random
House)
Mateus
Teixeira
(W.
W.
Norton)
Jonathan
Thurston
(Pearson
plc)
Daniel
Weck
(EDRLab)
Daniel
Weck
(DAISY
Consortium)
John
Weise
(University
of
Michigan
Library)
Jason
White
(Educational
Testing
Service)
David
Wood
(Ephox
Corporation)
Richard
Wright
(EDRLab)
Jeff
Xu
(Rakuten,Inc.)
Evan
Yamanishi
(W.
W.
Norton)
Maurice
York
(University
of
Michigan
Library)
Benjamin
Young
(Wiley)
The
Working
Group
would
also
like
to
thank
the
members
of
the
Digital
Publishing
Interest
Group
for
all
the
hard
work
they
did
paving
the
road
for
this
specification.
JSON-LD
1.0
.
Manu
Sporny;
Gregg
Kellogg;
Markus
Lanthaler.
W3C.
16
January
2014.
W3C
Recommendation.
URL:
https://www.w3.org/TR/json-ld/
[publishing-linking]
Publishing
and
Linking
on
the
Web
.
Ashok
Malhotra;
Larry
Masinter;
Jeni
Tennison;
Daniel
Appelquist.
W3C.
30
April
2013.
W3C
Note.
URL:
https://www.w3.org/TR/publishing-linking/
