resync 0.4.4 → 0.4.5
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.gitignore +50 -4
- data/.rubocop.yml +5 -0
- data/.ruby-version +1 -1
- data/CHANGES.md +10 -0
- data/Rakefile +4 -4
- data/lib/resync/capability_list.rb +3 -3
- data/lib/resync/link.rb +1 -1
- data/lib/resync/metadata.rb +1 -1
- data/lib/resync/resource.rb +1 -1
- data/lib/resync/shared/base_change_index.rb +1 -1
- data/lib/resync/shared/base_resource_list.rb +3 -3
- data/lib/resync/shared/descriptor.rb +3 -3
- data/lib/resync/shared/sorted_resource_list.rb +3 -6
- data/lib/resync/types/change.rb +1 -1
- data/lib/resync/types/change_frequency.rb +1 -1
- data/lib/resync/version.rb +1 -1
- data/lib/resync/xml.rb +1 -1
- data/lib/resync/xml_parser.rb +3 -3
- data/notes/resourcesync-1.0.9.html +3766 -0
- data/notes/resourcesync-1.0.html +3829 -0
- data/resync.gemspec +6 -5
- data/spec/.rubocop.yml +6 -0
- data/spec/acceptance/xml_parser_spec.rb +7 -7
- data/spec/rspec_custom_matchers.rb +3 -3
- data/spec/unit/resync/capability_list_spec.rb +1 -1
- data/spec/unit/resync/change_dump_manifest_spec.rb +2 -2
- data/spec/unit/resync/shared/augmented_examples.rb +1 -1
- data/spec/unit/resync/shared/base_resource_list_examples.rb +1 -1
- metadata +16 -15
|
@@ -0,0 +1,3829 @@
|
|
|
1
|
+
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
2
|
+
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
3
|
+
<head>
|
|
4
|
+
<title>ResourceSync Framework Specification</title>
|
|
5
|
+
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
|
|
6
|
+
<link rel="shortcut icon" href="img/favicon.ico" type="image/x-icon"/>
|
|
7
|
+
<link rel="stylesheet" href="css/resourcesync.css" type="text/css"/>
|
|
8
|
+
</head>
|
|
9
|
+
|
|
10
|
+
<body>
|
|
11
|
+
<div id="float-warning">
|
|
12
|
+
WARNING - SEE ALSO <a href="http://www.openarchives.org/rs/1.0.9/resourcesync">DRAFT REVISION</a>
|
|
13
|
+
</div>
|
|
14
|
+
<div id="header">
|
|
15
|
+
<table class="layout" summary="Logo and ResourceSync title">
|
|
16
|
+
<tbody><tr>
|
|
17
|
+
<td><img alt="NISO logo" src="img/niso_logo.png"/></td>
|
|
18
|
+
<td><img alt="OAI logo" src="img/OA100.gif" width="100" height="70"/></td>
|
|
19
|
+
<td class="OREtext">Open Archives Initiative<br/>ResourceSync Framework Specification</td>
|
|
20
|
+
<td><img alt="ResourceSync logo" src="img/resync_logo.jpg"/></td>
|
|
21
|
+
</tr>
|
|
22
|
+
</tbody>
|
|
23
|
+
</table>
|
|
24
|
+
</div>
|
|
25
|
+
<div id="titleBlock">
|
|
26
|
+
<h2 class="title">ResourceSync Framework Specification (ANSI/NISO Z39.99-2014)</h2>
|
|
27
|
+
<h3 class="subTitle">21 April 2014</h3>
|
|
28
|
+
</div><!--div-titleBlock-->
|
|
29
|
+
<dl>
|
|
30
|
+
<dt>This version:</dt>
|
|
31
|
+
<dd><a href="http://www.openarchives.org/rs/1.0/resourcesync">http://www.openarchives.org/rs/1.0/resourcesync</a></dd>
|
|
32
|
+
<dt>Latest version:</dt>
|
|
33
|
+
<dd><a href="http://www.openarchives.org/rs/resourcesync">http://www.openarchives.org/rs/resourcesync</a></dd>
|
|
34
|
+
<dt>Previous version:</dt>
|
|
35
|
+
<dd><a href="http://www.openarchives.org/rs/0.9.1/resourcesync">http://www.openarchives.org/rs/0.9.1/resourcesync</a></dd>
|
|
36
|
+
</dl>
|
|
37
|
+
|
|
38
|
+
<div class="abstract">
|
|
39
|
+
<h2><a name="abstract"></a>Abstract</h2>
|
|
40
|
+
<p>
|
|
41
|
+
This ResourceSync specification describes a synchronization framework for the web
|
|
42
|
+
consisting of various capabilities that allow third-party systems to remain synchronized
|
|
43
|
+
with a server's evolving resources. The capabilities may be combined in a modular manner
|
|
44
|
+
to meet local or community requirements. This specification also describes how a server
|
|
45
|
+
should advertise the synchronization capabilities it supports and how third-party systems
|
|
46
|
+
may discover this information. The specification repurposes the document formats defined
|
|
47
|
+
by the Sitemap protocol and introduces extensions for them.
|
|
48
|
+
</p>
|
|
49
|
+
</div>
|
|
50
|
+
|
|
51
|
+
<h2><a name="status"></a>Status of this Document</h2>
|
|
52
|
+
|
|
53
|
+
<p>This document is an HTML version of
|
|
54
|
+
<a href="http://www.niso.org/standards/z39-99-2014/">ANSI/NISO Z39.99-2014</a>,
|
|
55
|
+
an American National Standard developed by the
|
|
56
|
+
National Information Standards Organization.
|
|
57
|
+
Approved by the
|
|
58
|
+
American National Standards Institute (ANSI)
|
|
59
|
+
April 21, 2014. The <a href="#FrontMatter">front matter, authorship and acknowledgements</a>
|
|
60
|
+
of the PDF version are provided in Appendix C.</p>
|
|
61
|
+
|
|
62
|
+
<p>This specification is one of several documents comprising the
|
|
63
|
+
<a href="http://www.openarchives.org/rs/toc">ResourceSync Framework Specifications</a>.</p>
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
<div class="toc">
|
|
67
|
+
<h2><a name="contents"></a>Table of Contents</h2>
|
|
68
|
+
<p class="toc">
|
|
69
|
+
|
|
70
|
+
1. <a href="#Introduction">Introduction</a><br/>
|
|
71
|
+
1.1 <a href="#PurposeScope">Purpose and Scope</a><br/>
|
|
72
|
+
1.2 <a href="#MotivExamples">Motivating Examples</a><br/>
|
|
73
|
+
1.3 <a href="#Walkthrough">Walkthrough</a><br/>
|
|
74
|
+
|
|
75
|
+
2. <a href="#NormativeRefs">Normative References</a><br/>
|
|
76
|
+
|
|
77
|
+
3. <a href="#Definitions">Definitions</a><br/>
|
|
78
|
+
|
|
79
|
+
4. <a href="#Namespaces">Namespace Prefix Bindings</a><br/>
|
|
80
|
+
|
|
81
|
+
5. <a href="#SyncProcesses">Synchronization Processes</a><br/>
|
|
82
|
+
5.1 <a href="#SourcePers">Source Perspective</a><br/>
|
|
83
|
+
5.2 <a href="#DestPers">Destination Perspective</a><br/>
|
|
84
|
+
5.3 <a href="#Summary">Summary</a><br/>
|
|
85
|
+
|
|
86
|
+
6. <a href="#FrameworkOrg">Framework Organization</a><br/>
|
|
87
|
+
6.1 <a href="#Structure">Structure</a><br/>
|
|
88
|
+
6.2 <a href="#Navigation">Navigation</a><br/>
|
|
89
|
+
6.3 <a href="#Discovery">Discovery</a><br/>
|
|
90
|
+
6.3.1 <a href="#DiscoOverview">Overview</a><br/>
|
|
91
|
+
6.3.2 <a href="#wellknown">ResourceSync Well-Known URI</a><br/>
|
|
92
|
+
6.3.3 <a href="#disco_links">Links</a><br/>
|
|
93
|
+
6.3.4 <a href="#robots">robots.txt</a><br/>
|
|
94
|
+
|
|
95
|
+
7. <a href="#DocumentFormats">Sitemap Document Formats</a><br/>
|
|
96
|
+
|
|
97
|
+
8. <a href="#SourceDesc">Describing the Source</a><br/>
|
|
98
|
+
|
|
99
|
+
9. <a href="#CapabilityList">Advertising Capabilities</a><br/>
|
|
100
|
+
|
|
101
|
+
10. <a href="#DescResources">Describing Resources</a><br/>
|
|
102
|
+
10.1 <a href="#ResourceList">Resource List</a><br/>
|
|
103
|
+
10.2 <a href="#ResourceListIndex">Resource List Index</a><br/>
|
|
104
|
+
|
|
105
|
+
11. <a href="#PackResources">Packaging Resources</a><br/>
|
|
106
|
+
11.1 <a href="#ResourceDump">Resource Dump</a><br/>
|
|
107
|
+
11.1.1 <a href="#ResourceDumpManifest">Resource Dump Manifest</a><br/>
|
|
108
|
+
|
|
109
|
+
12. <a href="#DesChanges">Describing Changes</a><br/>
|
|
110
|
+
12.1 <a href="#ChangeList">Change List</a><br/>
|
|
111
|
+
12.2 <a href="#ChangeListIndex">Change List Index</a><br/>
|
|
112
|
+
|
|
113
|
+
13. <a href="#PackChanges">Packaging Changes</a><br/>
|
|
114
|
+
13.1 <a href="#ChangeDump">Change Dump</a><br/>
|
|
115
|
+
13.1.1 <a href="#ChangeDumpManifest">Change Dump Manifest</a><br/>
|
|
116
|
+
|
|
117
|
+
14. <a href="#LinkRelRes">Linking to Related Resources</a><br/>
|
|
118
|
+
14.1 <a href="#LinkRelResOverview">Overview</a><br/>
|
|
119
|
+
14.2 <a href="#MirCon">Mirrored Content</a><br/>
|
|
120
|
+
14.3 <a href="#AltRep">Alternate Representations</a><br/>
|
|
121
|
+
14.4 <a href="#PatchCon">Patching Content</a><br/>
|
|
122
|
+
14.5 <a href="#ResMDLinking">Resources and Metadata about Resources</a><br/>
|
|
123
|
+
14.6 <a href="#ResVers">Prior Versions of Resources</a><br/>
|
|
124
|
+
14.7 <a href="#ColMem">Collection Membership</a><br/>
|
|
125
|
+
14.8 <a href="#RePub">Republishing Resources</a><br/>
|
|
126
|
+
|
|
127
|
+
Appendix A. (normative) <a href="#TimeAttributeReqs">Time Attribute Requirements</a><br/>
|
|
128
|
+
Appendix B. <a href="#Bibliography">Bibliography</a><br/>
|
|
129
|
+
Appendix C. <a href="#FrontMatter">Front Matter, Authorship, Acknowledgements</a><br/>
|
|
130
|
+
Appendix D. <a href="#Changelog">Change Log</a>
|
|
131
|
+
</p>
|
|
132
|
+
</div>
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
<div class="body">
|
|
136
|
+
<h2>1. <a name="Introduction">Introduction</a></h2>
|
|
137
|
+
|
|
138
|
+
<h3>1.1 <a name="PurposeScope">Purpose and Scope</a></h3>
|
|
139
|
+
|
|
140
|
+
<p>The web is highly dynamic, with resources continuously being created,
|
|
141
|
+
updated, and deleted. As a result, using resources from a remote
|
|
142
|
+
server involves the challenge of remaining in step with its changing
|
|
143
|
+
content. In many cases, there is no need to reflect a
|
|
144
|
+
server's evolving content perfectly and, therefore, well-established
|
|
145
|
+
resource discovery techniques, such as crawling, suffice as an
|
|
146
|
+
updating mechanism. However, there are significant use cases that
|
|
147
|
+
require low latency and high accuracy in reflecting a remote server's
|
|
148
|
+
changing content. These requirements have typically been addressed by
|
|
149
|
+
ad-hoc technical approaches implemented within a small group of
|
|
150
|
+
collaborating systems. There have been no widely adopted, web-based
|
|
151
|
+
approaches.</p>
|
|
152
|
+
|
|
153
|
+
<p>This <strong>ResourceSync</strong> specification introduces a range
|
|
154
|
+
of easy to implement capabilities that a server may support in order
|
|
155
|
+
to enable remote systems to remain more tightly in step with its
|
|
156
|
+
evolving resources. It also describes how a server should advertise the
|
|
157
|
+
capabilities it supports. Remote systems may inspect this information
|
|
158
|
+
to determine how best to remain aligned with the evolving data.</p>
|
|
159
|
+
|
|
160
|
+
<p>Each capability provides a different synchronization functionality,
|
|
161
|
+
such as a list of the server's resources or its recently changed
|
|
162
|
+
resources, including what the nature of the change was: create,
|
|
163
|
+
update, or delete. All capabilities are implemented on the basis of
|
|
164
|
+
the document formats introduced by the
|
|
165
|
+
<a href="#ref-sitemaps">Sitemap protocol</a>. Capabilities may be
|
|
166
|
+
combined to achieve varying levels of functionality and hence meet
|
|
167
|
+
different local or community requirements. This modularity provides
|
|
168
|
+
flexibility and makes ResourceSync suitable for a broad range of use
|
|
169
|
+
cases.</p>
|
|
170
|
+
|
|
171
|
+
<h3>1.2 <a name="MotivExamples"></a>Motivating Examples</h3>
|
|
172
|
+
|
|
173
|
+
<p>Many projects and services have synchronization needs and have
|
|
174
|
+
implemented ad hoc solutions. ResourceSync provides a standard
|
|
175
|
+
synchronization method that will reduce implementation effort and
|
|
176
|
+
facilitate easier reuse of resources. This section describes motivating
|
|
177
|
+
examples with differing needs and complexities.</p>
|
|
178
|
+
|
|
179
|
+
<p>Consider first the case of a website for a small museum collection.
|
|
180
|
+
The website may contain just a few dozen static webpages. The
|
|
181
|
+
maintainer may create a <a href="#ResourceList">Resource List</a> of these
|
|
182
|
+
webpages and expose it to services that leverage ResourceSync.</p>
|
|
183
|
+
|
|
184
|
+
<p>When building services over Linked Data, it is often desirable to
|
|
185
|
+
maintain a local copy of data for improved access and availability.
|
|
186
|
+
Harvesting may be enabled by publishing a <a href="#ResourceList">Resource List</a>
|
|
187
|
+
for the dataset. In many cases, resource representations exposed as Linked Data are small and
|
|
188
|
+
so retrieving them via individual HTTP GET requests is slow because of the
|
|
189
|
+
large number of round trips for a small amount of content.
|
|
190
|
+
Publishing a <a href="#ResourceDump">Resource Dump</a> that points to content packaged and described in ZIP files makes
|
|
191
|
+
this more efficient for the client and less burdensome for the server.
|
|
192
|
+
Continued synchronization is enabled by recurrently publishing an up-to-date <a href="#ResourceList">Resource List</a> or <a href="#ResourceDump">Resource Dump</a>, or, more efficiently, by publishing a <a href="#ChangeList">Change List</a> that provides information about resource changes only.</p>
|
|
193
|
+
|
|
194
|
+
<p>
|
|
195
|
+
The <a href="http://arxiv.org/">arXiv.org</a> collection of scientific
|
|
196
|
+
articles propagates resource changes to a set of mirror sites and
|
|
197
|
+
interacting services on a daily basis. As of July 2013, the collection
|
|
198
|
+
contains about 2.6 million resources and there are about 1,600 changes
|
|
199
|
+
(creates, updates) per day. The mirroring system operated since 1994
|
|
200
|
+
uses HTTP with custom change descriptions and occasionally
|
|
201
|
+
<a href="http://en.wikipedia.org/wiki/Rsync">rsync</a> to verify the
|
|
202
|
+
copies and to cope with any errors in the incremental updates. The
|
|
203
|
+
approach assumes a tight connection between arXiv.org and its mirrors.
|
|
204
|
+
It would be desirable to have a solution that allows any
|
|
205
|
+
third-party system to accurately synchronize with arXiv.org using
|
|
206
|
+
commodity software. arXiv.org could publish both metadata records and
|
|
207
|
+
full-text content as separate web resources with their own URI.
|
|
208
|
+
Use of ResourceSync capabilities including
|
|
209
|
+
<a href="#ResourceList">Resource Lists</a>,
|
|
210
|
+
<a href="#ResourceDump">Resource Dumps</a>,
|
|
211
|
+
<a href="#ChangeList">Change Lists</a>, and
|
|
212
|
+
<a href="#ChangeDump">Change Dumps</a>, allows both mirrors and new parties
|
|
213
|
+
to remain accurately in sync with the collection. This would extend
|
|
214
|
+
the openly available metadata sharing capabilities provided by arXiv.org,
|
|
215
|
+
currently implemented via <a href="#ref-oaipmh">OAI-PMH</a>, to full-text
|
|
216
|
+
sharing in a web-friendly fashion.
|
|
217
|
+
</p>
|
|
218
|
+
|
|
219
|
+
|
|
220
|
+
<h3>1.3 <a name="Walkthrough">Walkthrough</a></h3>
|
|
221
|
+
|
|
222
|
+
<p>
|
|
223
|
+
Let's assume a Source, http://example.com/, that exposes changing content that others
|
|
224
|
+
would like to remain synchronized with. A first step towards making this easy for
|
|
225
|
+
Destinations is for the Source to publish a <a href="#ResourceList">Resource List</a>
|
|
226
|
+
that conveys the URIs of resources available for synchronization. This Resource List is
|
|
227
|
+
expressed as a Sitemap. As shown in <a href="#ex_1">Example 1</a>, the Source conveys
|
|
228
|
+
the URI of each resource as the value of the
|
|
229
|
+
<code><loc></code> child element of a
|
|
230
|
+
<code><url></code> element. Note the
|
|
231
|
+
<code><rs:md></code> child element of the <code><urlset></code>
|
|
232
|
+
root element, which expresses that the Sitemap implements ResourceSync's Resource List
|
|
233
|
+
capability. It also conveys that the Resource List reflects the state of the Source's
|
|
234
|
+
resources at the datetime provided in the <code>at</code> attribute. This datetime
|
|
235
|
+
allows a Destination to quickly determine whether it has previously processed this
|
|
236
|
+
specific Resource List.
|
|
237
|
+
</p>
|
|
238
|
+
|
|
239
|
+
<!--EXAMPLE:ex_1.xml-->
|
|
240
|
+
<a name="ex_1"></a>
|
|
241
|
+
<div class="exampleInner">
|
|
242
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
243
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
244
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
245
|
+
<rs:md capability="resourcelist"
|
|
246
|
+
at="2013-01-03T09:00:00Z"/>
|
|
247
|
+
<url>
|
|
248
|
+
<loc>http://example.com/res1</loc>
|
|
249
|
+
</url>
|
|
250
|
+
<url>
|
|
251
|
+
<loc>http://example.com/res2</loc>
|
|
252
|
+
</url>
|
|
253
|
+
</urlset>
|
|
254
|
+
</pre>
|
|
255
|
+
</div>
|
|
256
|
+
<p class="caption">Example 1: A Resource List</p>
|
|
257
|
+
<!--/EXAMPLE:ex_1.xml-->
|
|
258
|
+
|
|
259
|
+
<p>
|
|
260
|
+
The Source can provide additional information in the Resource List to
|
|
261
|
+
help the Destination optimize the process of collecting
|
|
262
|
+
content and verifying its accuracy. For example,
|
|
263
|
+
when the Source expresses the datetime of the most recent modification
|
|
264
|
+
for a resource, a Destination can determine whether or not it already
|
|
265
|
+
holds the current version, minimizing the number of HTTP requests it
|
|
266
|
+
needs to issue in order to remain up-to-date. <a href="#ex_2">Example 2</a>
|
|
267
|
+
shows this information
|
|
268
|
+
conveyed using Sitemap's <code><lastmod></code> element.
|
|
269
|
+
When the Source also conveys a hash for a specific bitstream, a Destination
|
|
270
|
+
can verify whether the process of obtaining it was successful.
|
|
271
|
+
The example shows this information conveyed using the <code>hash</code>
|
|
272
|
+
attribute on the <code><rs:md></code> element.
|
|
273
|
+
In addition, the Source can provide links to related resources using the
|
|
274
|
+
<code><rs:ln></code> element. The example shows a link to a mirror
|
|
275
|
+
copy of the second listed resource, indicating that the Source would prefer
|
|
276
|
+
a Destination to obtain the resource from it.
|
|
277
|
+
</p>
|
|
278
|
+
|
|
279
|
+
<!--EXAMPLE:ex_2.xml-->
|
|
280
|
+
<a name="ex_2"></a>
|
|
281
|
+
<div class="exampleInner">
|
|
282
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
283
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
284
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
285
|
+
<rs:md capability="resourcelist"
|
|
286
|
+
at="2013-01-03T09:00:00Z"/>
|
|
287
|
+
<url>
|
|
288
|
+
<loc>http://example.com/res1</loc>
|
|
289
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
290
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"/>
|
|
291
|
+
</url>
|
|
292
|
+
<url>
|
|
293
|
+
<loc>http://example.com/res2</loc>
|
|
294
|
+
<lastmod>2013-01-02T14:00:00Z</lastmod>
|
|
295
|
+
<rs:md hash="md5:1e0d5cb8ef6ba40c99b14c0237be735e"/>
|
|
296
|
+
<rs:ln rel="duplicate"
|
|
297
|
+
href="http://mirror.example.com/res2"/>
|
|
298
|
+
</url>
|
|
299
|
+
</urlset>
|
|
300
|
+
</pre>
|
|
301
|
+
</div>
|
|
302
|
+
<p class="caption">Example 2: A Resource List with additional information</p>
|
|
303
|
+
<!--/EXAMPLE:ex_2.xml-->
|
|
304
|
+
|
|
305
|
+
<p>
|
|
306
|
+
In order to describe its changing content in a more timely manner, the
|
|
307
|
+
Source can increase the frequency at which it publishes an up-to-date
|
|
308
|
+
Resource List. However, changes may be so frequent or the size of the content
|
|
309
|
+
collection so vast that regularly updating a complete Resource List may
|
|
310
|
+
be impractical. In such cases, the Source can implement an additional
|
|
311
|
+
capability that communicates information about changes
|
|
312
|
+
only. To this end, ResourceSync introduces Change Lists. A Change List
|
|
313
|
+
enumerates resource changes, along with the nature of the
|
|
314
|
+
change (create, update, or delete) and the time that the change occurred.
|
|
315
|
+
A Destination can recurrently obtain a Change List from the Source,
|
|
316
|
+
inspect the listed changes to discover those it has already acted upon,
|
|
317
|
+
and process the remaining ones. Changes in a Change List are provided
|
|
318
|
+
in forward chronological order, making it straightforward for a
|
|
319
|
+
Destination to determine which changes it already processed. In addition,
|
|
320
|
+
a Change List also contains datetimes that convey the start time and
|
|
321
|
+
the end time of the temporal interval covered by the Change List.
|
|
322
|
+
These times convey that all resource changes that
|
|
323
|
+
occurred during the interval are described in the Change List.
|
|
324
|
+
(ResourceSync does not specify for how long change lists must
|
|
325
|
+
continue to be available once they have been produced. The
|
|
326
|
+
longer that Change Lists are maintained by the Source, the
|
|
327
|
+
better the odds are for a Destination to catch up on changes
|
|
328
|
+
it missed because it was offline, for example.)
|
|
329
|
+
</p>
|
|
330
|
+
|
|
331
|
+
<p><a href="#ex_3">Example 3</a> shows a Change List.
|
|
332
|
+
The value of the <code>capability</code> attribute of the <code><rs:md></code>
|
|
333
|
+
child element of <code><urlset></code> makes it clear that, this time,
|
|
334
|
+
the Sitemap is a Change List and not a Resource List. The <code>from</code>
|
|
335
|
+
and <code>until</code> attributes inform about the temporal interval covered
|
|
336
|
+
by the Change List. The Change List shown below conveys two
|
|
337
|
+
resource changes, one an update and the other a deletion, as can be
|
|
338
|
+
seen from the value of the <code>change</code> attribute of the
|
|
339
|
+
<code><rs:md></code> element. The example also shows the use of the
|
|
340
|
+
<code><lastmod></code> element to convey the time of the changes. Note that these times are used to
|
|
341
|
+
order the Change List chronologically.
|
|
342
|
+
</p>
|
|
343
|
+
|
|
344
|
+
<!--EXAMPLE:ex_3.xml-->
|
|
345
|
+
<a name="ex_3"></a>
|
|
346
|
+
<div class="exampleInner">
|
|
347
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
348
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
349
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
350
|
+
<rs:md capability="changelist"
|
|
351
|
+
from="2013-01-02T00:00:00Z"
|
|
352
|
+
until="2013-01-03T00:00:00Z"/>
|
|
353
|
+
<url>
|
|
354
|
+
<loc>http://example.com/res2.pdf</loc>
|
|
355
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
356
|
+
<rs:md change="updated"/>
|
|
357
|
+
</url>
|
|
358
|
+
<url>
|
|
359
|
+
<loc>http://example.com/res3.tiff</loc>
|
|
360
|
+
<lastmod>2013-01-02T18:00:00Z</lastmod>
|
|
361
|
+
<rs:md change="deleted"/>
|
|
362
|
+
</url>
|
|
363
|
+
</urlset>
|
|
364
|
+
</pre>
|
|
365
|
+
</div>
|
|
366
|
+
<p class="caption">Example 3: A Change List</p>
|
|
367
|
+
<!--/EXAMPLE:ex_3.xml-->
|
|
368
|
+
|
|
369
|
+
<p>A Destination can issue HTTP GET requests against each resource URI listed in a Resource List. For
|
|
370
|
+
large Resource Lists, issuing all of these requests may be cumbersome. Therefore, ResourceSync introduces a
|
|
371
|
+
capability that a Source can use to
|
|
372
|
+
make packaged content available. A Resource Dump, implemented as a Sitemap, contains pointers to packaged content.
|
|
373
|
+
Each content package referenced in a Resource Dump is a ZIP file that contains the Source's bitstreams along with a Resource Dump Manifest
|
|
374
|
+
that describes each. The Resource Dump Manifest itself is also implemented as a Sitemap.
|
|
375
|
+
A Destination can retrieve a Resource Dump, obtain content packages by dereferencing the contained pointers, and unpack the retrieved packages.
|
|
376
|
+
Since the Resource Dump Manifest also lists the URI the Source associates with each bitstream, a Destination is able to achieve
|
|
377
|
+
the same result as obtaining the data by dereferencing the URIs listed in a Resource List.
|
|
378
|
+
<a href="#ex_4">Example 4</a> shows a Resource Dump that points at a single content package. Dereferencing the URI of that package leads to a ZIP file
|
|
379
|
+
that contains the Resource Dump Manifest shown in
|
|
380
|
+
<a href="#ex_5">Example 5</a>. It indicates that the Source's ZIP file contains two bitstreams.
|
|
381
|
+
The <code>path</code> attribute of the <code><rs:md></code> element conveys
|
|
382
|
+
the file path of the bitstream in the ZIP file (the relative file system path where the bitstream
|
|
383
|
+
would reside if the ZIP were unpacked), whereas the <code><loc></code> element conveys the URI associated with the bitstream at the Source.
|
|
384
|
+
</p>
|
|
385
|
+
|
|
386
|
+
<p>An additional capability, the Change Dump, provides a functionality similar to a Resource Dump but pertains to
|
|
387
|
+
packaging bitstreams of resources that have changed during a temporal interval,
|
|
388
|
+
instead of packaging a snapshot of resource bitstreams at a specific moment in time.</p>
|
|
389
|
+
|
|
390
|
+
<!--EXAMPLE:ex_4.xml-->
|
|
391
|
+
<a name="ex_4.xml"></a>
|
|
392
|
+
<div class="exampleInner">
|
|
393
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
394
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
395
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
396
|
+
<rs:md capability="resourcedump"
|
|
397
|
+
at="2013-01-03T09:00:00Z"/>
|
|
398
|
+
<url>
|
|
399
|
+
<loc>http://example.com/resourcedump.zip</loc>
|
|
400
|
+
<lastmod>2013-01-03T09:00:00Z</lastmod>
|
|
401
|
+
</url>
|
|
402
|
+
</urlset>
|
|
403
|
+
</pre>
|
|
404
|
+
</div>
|
|
405
|
+
<p class="caption">Example 4: A Resource Dump</p>
|
|
406
|
+
<!--/EXAMPLE:ex_4.xml-->
|
|
407
|
+
|
|
408
|
+
<!--EXAMPLE:ex_5.xml-->
|
|
409
|
+
<a name="ex_5"></a>
|
|
410
|
+
<div class="exampleInner">
|
|
411
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
412
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
413
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
414
|
+
<rs:md capability="resourcedump-manifest"
|
|
415
|
+
at="2013-01-03T09:00:00Z"/>
|
|
416
|
+
<url>
|
|
417
|
+
<loc>http://example.com/res1</loc>
|
|
418
|
+
<lastmod>2013-01-03T03:00:00Z</lastmod>
|
|
419
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
420
|
+
path="/resources/res1"/>
|
|
421
|
+
</url>
|
|
422
|
+
<url>
|
|
423
|
+
<loc>http://example.com/res2</loc>
|
|
424
|
+
<lastmod>2013-01-03T04:00:00Z</lastmod>
|
|
425
|
+
<rs:md hash="md5:1e0d5cb8ef6ba40c99b14c0237be735e"
|
|
426
|
+
path="/resources/res2"/>
|
|
427
|
+
</url>
|
|
428
|
+
</urlset>
|
|
429
|
+
</pre>
|
|
430
|
+
</div>
|
|
431
|
+
<p class="caption">Example 5: A Resource Dump Manifest detailing the content of a ZIP file</p>
|
|
432
|
+
<!--/EXAMPLE:ex_5.xml-->
|
|
433
|
+
|
|
434
|
+
<p>ResourceSync also introduces a Capability List, which is a way for the
|
|
435
|
+
Source to describe the capabilities it supports for one set of resources.
|
|
436
|
+
<a href="#ex_6">Example 6</a> shows an example of such a description.
|
|
437
|
+
It indicates that the Source supports the Resource List, Resource Dump, and
|
|
438
|
+
Change List capabilities and it lists their respective URIs. Note the
|
|
439
|
+
inclusion of an <code><rs:ln></code> child element of <code><urlset></code>
|
|
440
|
+
that links by means of a <code>describedby</code> relation
|
|
441
|
+
to a description of the set of resources covered by the Capability List.
|
|
442
|
+
Because these capabilities are conveyed in the same Capability List, they
|
|
443
|
+
uniformly apply to this set of resources. For example, if a given resource
|
|
444
|
+
appears in the Resource List then it must also appear in a Resource Dump
|
|
445
|
+
and changes to the resource must be reported in the Change List.
|
|
446
|
+
</p>
|
|
447
|
+
|
|
448
|
+
<!--EXAMPLE:ex_6.xml-->
|
|
449
|
+
<a name="ex_6"></a>
|
|
450
|
+
<div class="exampleInner">
|
|
451
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
452
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
453
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
454
|
+
<rs:ln rel="describedby"
|
|
455
|
+
href="http://example.com/info_about_set1_of_resources.xml"/>
|
|
456
|
+
<rs:ln rel="up"
|
|
457
|
+
href="http://example.com/resourcesync_description.xml"/>
|
|
458
|
+
<rs:md capability="capabilitylist"/>
|
|
459
|
+
<url>
|
|
460
|
+
<loc>http://example.com/dataset1/resourcelist.xml</loc>
|
|
461
|
+
<rs:md capability="resourcelist"/>
|
|
462
|
+
</url>
|
|
463
|
+
<url>
|
|
464
|
+
<loc>http://example.com/dataset1/resourcedump.xml</loc>
|
|
465
|
+
<rs:md capability="resourcedump"/>
|
|
466
|
+
</url>
|
|
467
|
+
<url>
|
|
468
|
+
<loc>http://example.com/dataset1/changelist.xml</loc>
|
|
469
|
+
<rs:md capability="changelist"/>
|
|
470
|
+
</url>
|
|
471
|
+
</urlset>
|
|
472
|
+
</pre>
|
|
473
|
+
</div>
|
|
474
|
+
<p class="caption">Example 6: A Capability List enumerating the ResourceSync capabilities a Source supports for a set of its resources</p>
|
|
475
|
+
<!--/EXAMPLE:ex_6.xml-->
|
|
476
|
+
|
|
477
|
+
<p>
|
|
478
|
+
There are three ways by which a Destination can discover whether and how a Source
|
|
479
|
+
supports ResourceSync: a Source-wide approach, a resource-specific approach, and
|
|
480
|
+
an approach that leverages existing practice for discovering Sitemaps.
|
|
481
|
+
The Source-wide approach leverages the well-known URI specification
|
|
482
|
+
and consists of the Source making a Source Description, like the one shown in
|
|
483
|
+
<a href="#ex_7">Example 7</a>, available at
|
|
484
|
+
<code>/.well-known/resourcesync</code>. The Source Description enumerates the
|
|
485
|
+
Capability Lists a Source offers, one Capability List per set of resources. If a
|
|
486
|
+
Source only has one set of resources and hence only one Capability List, the
|
|
487
|
+
mandatory Source Description contains only one pointer. The resource-specific
|
|
488
|
+
discovery approach
|
|
489
|
+
consists of a Source providing a link in an HTML document or in an HTTP Link header
|
|
490
|
+
that points at a Capability List that covers the resource that provides the link. Note
|
|
491
|
+
in <a href="#ex_6">Example 6</a>, the inclusion of an <code><rs:ln></code> child
|
|
492
|
+
element of <code><urlset></code> that links by means of an <code>up</code> relation
|
|
493
|
+
to the Source Description, allowing for navigation from a Capability List to a Source
|
|
494
|
+
Description. Yet another approach follows the established practice for discovering
|
|
495
|
+
Sitemaps via a Source's <code>robots.txt</code> file. Since a Resource List is a
|
|
496
|
+
Sitemap it can be made discoverable by including its URI in the <code>robots.txt</code>
|
|
497
|
+
file as the value of the <code>Sitemap</code> directive. A navigational <code>up</code>
|
|
498
|
+
link included in the Resource List allows discovery of a Capability List pertaining
|
|
499
|
+
to the set of resources covered by that Resource List, and a further
|
|
500
|
+
<code>up</code> link in the Capability List leads to the Source Description.
|
|
501
|
+
</p>
|
|
502
|
+
|
|
503
|
+
<!--EXAMPLE:ex_7.xml-->
|
|
504
|
+
<a name="ex_7"></a>
|
|
505
|
+
<div class="exampleInner">
|
|
506
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
507
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
508
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
509
|
+
<rs:ln rel="describedby"
|
|
510
|
+
href="http://example.com/info-about-source.xml"/>
|
|
511
|
+
<rs:md capability="description"/>
|
|
512
|
+
<url>
|
|
513
|
+
<loc>http://example.com/dataset1/capabilitylist.xml</loc>
|
|
514
|
+
<rs:md capability="capabilitylist"/>
|
|
515
|
+
<rs:ln rel="describedby"
|
|
516
|
+
href="http://example.com/info_about_set1_of_resources.xml"/>
|
|
517
|
+
</url>
|
|
518
|
+
</urlset>
|
|
519
|
+
</pre>
|
|
520
|
+
</div>
|
|
521
|
+
<p class="caption">Example 7: A Source Description with a pointer to the Capability List for the single set of resources offered by a Source</p>
|
|
522
|
+
<!--/EXAMPLE:ex_7.xml-->
|
|
523
|
+
|
|
524
|
+
<p>In some cases, there is a need to split the documents described so far into parts.
|
|
525
|
+
For example, the Sitemap protocol currently prescribes a maximum of 50,000 resources
|
|
526
|
+
per Sitemap and a Source may have more resources that are subject to synchronization.
|
|
527
|
+
The ResourceSync framework follows these community defined limits and hence,
|
|
528
|
+
in such cases, publishes multiple Resource Lists as well as a Resource List Index
|
|
529
|
+
that points to each of them. The Resource List Index is expressed using
|
|
530
|
+
Sitemap's <code><sitemapindex></code> document format.
|
|
531
|
+
<a href="#ex_8">Example 8</a> shows a Resource List Index that points at two Resource
|
|
532
|
+
Lists.</p>
|
|
533
|
+
|
|
534
|
+
<!--EXAMPLE:ex_8.xml-->
|
|
535
|
+
<a name="ex_8"></a>
|
|
536
|
+
<div class="exampleInner">
|
|
537
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
538
|
+
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
539
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
540
|
+
<rs:md capability="resourcelist"
|
|
541
|
+
at="2013-01-03T09:00:00Z"/>
|
|
542
|
+
<sitemap>
|
|
543
|
+
<loc>http://example.com/resourcelist-part1.xml</loc>
|
|
544
|
+
</sitemap>
|
|
545
|
+
<sitemap>
|
|
546
|
+
<loc>http://example.com/resourcelist-part2.xml</loc>
|
|
547
|
+
</sitemap>
|
|
548
|
+
</sitemapindex>
|
|
549
|
+
</pre>
|
|
550
|
+
</div>
|
|
551
|
+
<p class="caption">Example 8: A Resource List Index expressed using the <code><sitemapindex></code> document format</p>
|
|
552
|
+
<!--/EXAMPLE:ex_8.xml-->
|
|
553
|
+
|
|
554
|
+
|
|
555
|
+
<h2>2. <a name="NormativeRefs">Normative References</a></h2>
|
|
556
|
+
|
|
557
|
+
<p>
|
|
558
|
+
The following documents contain provisions that are required for implementing
|
|
559
|
+
this standard. All standards are subject to revision; the most current version
|
|
560
|
+
of these standards should be used.
|
|
561
|
+
</p>
|
|
562
|
+
|
|
563
|
+
<dl>
|
|
564
|
+
<dt>[<a name="ref-ale" id="ref-ale">ALE</a>]</dt>
|
|
565
|
+
<dd>Snell, J.
|
|
566
|
+
<a href="http://tools.ietf.org/html/draft-snell-atompub-link-extensions-09"><cite>Atom Link Extensions</cite></a>.
|
|
567
|
+
Internet Draft. Internet Engineering Task Force (IETF), June 8, 2012.
|
|
568
|
+
Available at: <a href="http://tools.ietf.org/html/draft-snell-atompub-link-extensions-09">http://tools.ietf.org/html/draft-snell-atompub-link-extensions-09</a></dd>
|
|
569
|
+
|
|
570
|
+
<dt>[<a name="ref-iana-mime" id="ref-iana-mime">IANA MIME</a>]</dt>
|
|
571
|
+
<dd><a href="http://www.iana.org/assignments/media-types"><cite>MIME Media Types</cite></a> [registry website].
|
|
572
|
+
Internet Assigned Numbers Authority (IANA).
|
|
573
|
+
Available at: <a href="http://www.iana.org/assignments/media-types">http://www.iana.org/assignments/media-types</a></dd>
|
|
574
|
+
|
|
575
|
+
<dt>[<a name="ref-iana-rel" id="ref-iana-rel">IANA Relation</a>]</dt>
|
|
576
|
+
<dd><a href="http://www.iana.org/assignments/link-relations/link-relations.xml"><cite>Link Relations</cite></a> [registry website].
|
|
577
|
+
Internet Assigned Numbers Authority (IANA).
|
|
578
|
+
Available at: <a href="http://www.iana.org/assignments/link-relations/link-relations.xml">http://www.iana.org/assignments/link-relations/link-relations.xml</a></dd>
|
|
579
|
+
|
|
580
|
+
<dt>[<a name="ref-memento" id="ref-memento">Memento</a>]</dt>
|
|
581
|
+
<dd>Van de Sompel, H., M. L. Nelson, and R. D. Sanderson.
|
|
582
|
+
<a href="http://tools.ietf.org/html/draft-vandesompel-memento-10"><cite>HTTP framework for time-based access to resource states -- Memento. Internet Draft</cite></a>.
|
|
583
|
+
Internet Engineering Task Force (IETF), October 1, 2013.
|
|
584
|
+
Available at: <a href="http://tools.ietf.org/html/draft-vandesompel-memento-10">http://tools.ietf.org/html/draft-vandesompel-memento-10</a></dd>
|
|
585
|
+
|
|
586
|
+
<dt>[<a name="ref-rfc2616" id="ref-rfc2616">RFC 2616</a>]</dt>
|
|
587
|
+
<dd>Fielding, R. <i>et al.</i>
|
|
588
|
+
<cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol -- HTTP/1.1</a></cite>. RFC 2616.
|
|
589
|
+
Internet Engineering Task Force (IETF), June 1999.
|
|
590
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a></dd>
|
|
591
|
+
|
|
592
|
+
<dt>[<a name="ref-rfc4287" id="ref-rfc4287">RFC 4287</a>]</dt>
|
|
593
|
+
<dd>Nottingham, M., and R. Sayre, <i>eds.</i>
|
|
594
|
+
<cite><a href="http://www.ietf.org/rfc/rfc4287.txt">The Atom Syndication Format</a></cite>. RFC 4287.
|
|
595
|
+
Internet Engineering Task Force (IETF), December 2005.
|
|
596
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc4287.txt">http://www.ietf.org/rfc/rfc4287.txt</a></dd>
|
|
597
|
+
|
|
598
|
+
<dt>[<a name="ref-rfc5988" id="ref-rfc5988">RFC 5988</a>]</dt>
|
|
599
|
+
<dd>Nottingham, M.
|
|
600
|
+
<cite><a href="http://www.ietf.org/rfc/rfc5988.txt">Web Linking</a></cite>. RFC 5988.
|
|
601
|
+
Internet Engineering Task Force (IETF), October 2010.
|
|
602
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc5988.txt">http://www.ietf.org/rfc/rfc5988.txt</a></dd>
|
|
603
|
+
|
|
604
|
+
<dt>[<a name="ref-rfc6249" id="ref-rfc6249">RFC 6249</a>]</dt>
|
|
605
|
+
<dd>Bryan, A. <i>et al.</i>
|
|
606
|
+
<cite><a href="http://www.ietf.org/rfc/rfc6249.txt">Metalink/HTTP: Mirrors and Hashes</a></cite>. RFC 6249.
|
|
607
|
+
Internet Engineering Task Force (IETF), June 2011.
|
|
608
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc6249.txt">http://www.ietf.org/rfc/rfc6249.txt</a></dd>
|
|
609
|
+
|
|
610
|
+
<dt>[<a name="ref-rfc6906" id="ref-rfc6906">RFC 6906</a>]</dt>
|
|
611
|
+
<dd>Wilde, E.
|
|
612
|
+
<cite><a href="http://www.ietf.org/rfc/rfc6906.txt">The 'profile' Link Relation Type.</a></cite> RFC 6906.
|
|
613
|
+
Internet Engineering Task Force (IETF), March 2013.
|
|
614
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc6906.txt">http://www.ietf.org/rfc/rfc6906.txt</a></dd>
|
|
615
|
+
|
|
616
|
+
<dt>[<a name="ref-sitemaps" id="ref-sitemaps">Sitemaps</a>]</dt>
|
|
617
|
+
<dd><cite><a href="http://www.sitemaps.org/protocol.html">Sitemaps XML Format</a></cite>.
|
|
618
|
+
sitemaps.org, last updated February 27, 2008.
|
|
619
|
+
Available at: <a href="http://www.sitemaps.org/protocol.html">http://www.sitemaps.org/protocol.html</a></dd>
|
|
620
|
+
|
|
621
|
+
<dt>[<a name="w3c-datetime" id="w3c-datetime">W3C Datetime</a>]</dt>
|
|
622
|
+
<dd>Wolf, Misha, and Charles Wicksteed.
|
|
623
|
+
<cite><a href="http://www.w3.org/TR/1998/NOTE-datetime-19980827">Date and Time Formats</a></cite>. W3C Note.
|
|
624
|
+
World Wide Web Consortium, August 27, 1998.
|
|
625
|
+
Available at: <a href="http://www.w3.org/TR/1998/NOTE-datetime-19980827">http://www.w3.org/TR/1998/NOTE-datetime-19980827</a></dd>
|
|
626
|
+
|
|
627
|
+
<dt>[<a name="ref-zip" id="ref-zip">ZIP</a>]</dt>
|
|
628
|
+
<dd><cite><a href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">.ZIP File Format Specification</a></cite>. Application Note. Version 6.3.3.
|
|
629
|
+
PKWARE Inc., September 1, 2012.
|
|
630
|
+
Available at: <a href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT"> http://www.pkware.com/documents/casestudies/APPNOTE.TXT</a></dd>
|
|
631
|
+
|
|
632
|
+
</dl>
|
|
633
|
+
|
|
634
|
+
|
|
635
|
+
<h2>3. <a name="Definitions">Definitions</a></h2>
|
|
636
|
+
|
|
637
|
+
<p>
|
|
638
|
+
The following terms, as used in this standard, have the meanings indicated.
|
|
639
|
+
</p>
|
|
640
|
+
|
|
641
|
+
<a name="tab_1"></a>
|
|
642
|
+
<table class="namespace-table" summary="Definitions">
|
|
643
|
+
<tbody><tr class="top">
|
|
644
|
+
<th class="left">Term</th><th class="left">Definition</th>
|
|
645
|
+
</tr>
|
|
646
|
+
<tr class="odd">
|
|
647
|
+
<td class="left">Source</td>
|
|
648
|
+
<td class="left">A server that hosts resources subject to synchronization</td>
|
|
649
|
+
</tr>
|
|
650
|
+
<tr class="odd">
|
|
651
|
+
<td class="left">Destination</td>
|
|
652
|
+
<td class="left">A system that synchronizes itself with the Source's resources</td>
|
|
653
|
+
</tr>
|
|
654
|
+
<tr class="odd">
|
|
655
|
+
<td class="left">set of resources</td>
|
|
656
|
+
<td class="left">A collection of resources that is made available for synchronization by a
|
|
657
|
+
Source. A Source may expose one or more such collections and support distinct
|
|
658
|
+
ResourceSync capabilities for each. Individual resources may be included in
|
|
659
|
+
more than one set of resources</td>
|
|
660
|
+
</tr>
|
|
661
|
+
</tbody></table>
|
|
662
|
+
|
|
663
|
+
<p>This specification uses the terms <i>resource</i>, <i>representation</i>, <i>request</i>,
|
|
664
|
+
<i>response</i>, <i>content negotiation</i>, <i>client</i>, and <i>server</i> as
|
|
665
|
+
described in <a href="#ref-webarch">Architecture of the World Wide Web</a>.</p>
|
|
666
|
+
|
|
667
|
+
|
|
668
|
+
<h2>4. <a name="Namespaces">Namespace Prefix Bindings</a></h2>
|
|
669
|
+
|
|
670
|
+
<p>Throughout this document, the following namespace prefix bindings
|
|
671
|
+
are used:</p>
|
|
672
|
+
|
|
673
|
+
<a name="tab_1"></a>
|
|
674
|
+
<table class="namespace-table" summary="Namespaces used in this document">
|
|
675
|
+
<tbody><tr class="top">
|
|
676
|
+
<th class="left">Prefix</th><th class="center">Namespace URI</th><th class="right">Description</th>
|
|
677
|
+
</tr>
|
|
678
|
+
<tr class="odd">
|
|
679
|
+
<td class="left"></td><td class="center"><code>http://www.sitemaps.org/schemas/sitemap/0.9</code></td>
|
|
680
|
+
<td class="right">Sitemap XML elements defined in the <a href="#ref-sitemaps">Sitemap protocol</a></td>
|
|
681
|
+
</tr>
|
|
682
|
+
<tr class="even">
|
|
683
|
+
<td class="left"><code>rs</code></td><td class="center"><code>http://www.openarchives.org/rs/terms/</code></td>
|
|
684
|
+
<td class="right">Namespace for elements introduced in this specification</td>
|
|
685
|
+
</tr>
|
|
686
|
+
</tbody></table>
|
|
687
|
+
|
|
688
|
+
|
|
689
|
+
<h2>5. <a name="SyncProcesses">Synchronization Processes</a></h2>
|
|
690
|
+
|
|
691
|
+
<p>
|
|
692
|
+
<a href="#Walkthrough">Section 1.3</a> provides a concrete walkthrough of some
|
|
693
|
+
capabilities that a Source may implement and describes how a
|
|
694
|
+
Destination may use those capabilities to remain synchronized with
|
|
695
|
+
the Source's changing data. This section provides a high-level
|
|
696
|
+
overview of the various ResourceSync capabilities and shows how
|
|
697
|
+
these fit into processes at a Destination designed to keep it in
|
|
698
|
+
step with changes.
|
|
699
|
+
</p>
|
|
700
|
+
|
|
701
|
+
<h3>5.1 <a name="SourcePers">Source Perspective</a></h3>
|
|
702
|
+
|
|
703
|
+
<p>From the perspective of a <b>Source</b>, the ResourceSync capabilities
|
|
704
|
+
that may be supported to enable Destination processes to remain in
|
|
705
|
+
sync with its changing data are summarized as follows:
|
|
706
|
+
</p>
|
|
707
|
+
|
|
708
|
+
<ul>
|
|
709
|
+
<li><b>Describing Content</b> -- In order to describe its data, a
|
|
710
|
+
Source may maintain an up-to-date <b>Resource List</b>. A
|
|
711
|
+
basic Resource List minimally provides the URIs of resources
|
|
712
|
+
that the Source makes available for synchronization. However,
|
|
713
|
+
additional information may be added to the Resource List to optimize
|
|
714
|
+
the Destination's process of obtaining the Source's resources,
|
|
715
|
+
including the most recent modification time of resources and fixity
|
|
716
|
+
information such as content-based checksum or hash and length.
|
|
717
|
+
<a href="#fig_source_perspective">Figure 1</a> shows a Source
|
|
718
|
+
publishing up-to-date Resource Lists at times t2 and t4. At t4,
|
|
719
|
+
too many resources need to be listed to fit in a single
|
|
720
|
+
Resource List and hence multiple Resource Lists are published and
|
|
721
|
+
grouped in a Resource List Index.
|
|
722
|
+
</li>
|
|
723
|
+
<li><b>Packaging Content</b> -- In order to make its data available for
|
|
724
|
+
download, a Source may recurrently make an up-to-date <b>Resource Dump</b>
|
|
725
|
+
of its content available. A Resource Dump points at one or more packages,
|
|
726
|
+
each of which contains bitstreams associated with resources hosted by the Source.
|
|
727
|
+
Each package also contains a <b>Resource Dump Manifest</b> that provides
|
|
728
|
+
metadata about the bitstreams contained in the package, and must minimally
|
|
729
|
+
include their associated URI and their file path in the ZIP file.
|
|
730
|
+
<a href="#fig_source_perspective">Figure 1</a> shows a Source publishing
|
|
731
|
+
up-to-date Resource Dumps at times t1 and t3. At time t3, multiple
|
|
732
|
+
Resource Dumps are published and grouped in a Resource Dump Index.
|
|
733
|
+
</li>
|
|
734
|
+
<li><b>Describing Changes</b> -- In order to achieve lower
|
|
735
|
+
synchronization latency and/or to improve transfer efficiency,
|
|
736
|
+
a Source may publish a Change List that provides information about
|
|
737
|
+
changes to its resources. It is up to the Source to decide the temporal
|
|
738
|
+
interval covered by a Change List, for example, all the changes
|
|
739
|
+
that occurred during the previous hour, the current day, or since
|
|
740
|
+
the most recent publication of a Resource List. For each resource
|
|
741
|
+
change, a Change List must minimally convey the URI of the changed
|
|
742
|
+
resource as well as the datetime and nature of the change (create,
|
|
743
|
+
update, delete). Since a Change List is organized on the basis of
|
|
744
|
+
changes, it may list the same resource multiple times, once per change.
|
|
745
|
+
<a href="#fig_source_perspective">Figure 2</a> shows three Change Lists.
|
|
746
|
+
The first Change List covers resource changes that occurred between
|
|
747
|
+
t1 and t3, the second between t3 and t5, and the third between t5 and t7.
|
|
748
|
+
Since too many changes occurred between t5 and t7 to fit in a single
|
|
749
|
+
Change List, multiple Change Lists are published and grouped in a
|
|
750
|
+
Change List Index.
|
|
751
|
+
</li>
|
|
752
|
+
<li><b>Packaging Changes</b> -- In order to make content changes available for download,
|
|
753
|
+
a Source may publish a <b>Change Dump</b>. A Change Dump points at one or more packages,
|
|
754
|
+
each of which contains bitstreams that correspond to the state of resources after they changed.
|
|
755
|
+
Each package also contains a <b>Change Dump Manifest</b> that provides metadata about the
|
|
756
|
+
bitstreams provided in the Change Dump.
|
|
757
|
+
For each bitstream, the Change Dump Manifest must minimally include the associated URI, the
|
|
758
|
+
datetime when the change that resulted in the bitstream occurred, the nature of the
|
|
759
|
+
change (create, update, delete) and, where appropriate, the file path of the bitstream
|
|
760
|
+
in the ZIP file.
|
|
761
|
+
It is up to a Source to decide the temporal interval covered by a
|
|
762
|
+
Change Dump, for example, covering all the resource changes that occurred during the
|
|
763
|
+
previous hour, the current day, or since the most recent publication
|
|
764
|
+
of a Resource Dump. Since a Change Dump is organized on the basis of changes,
|
|
765
|
+
the package(s) it points at may contain multiple bitstreams associated with any given
|
|
766
|
+
resource, one per change. <a href="#fig_source_perspective">Figure 2</a>
|
|
767
|
+
shows three Change Dumps. The first Change Dump covers resource changes
|
|
768
|
+
that occurred between t2 and t4, the second between t4 and t6, and the third
|
|
769
|
+
between t6 and t8. During the time period between t6 and t8, multiple
|
|
770
|
+
Change Dumps are published and grouped in a Change Dump Index.
|
|
771
|
+
</li>
|
|
772
|
+
<li><b>Linking to Related Resources</b> -- There are several reasons to
|
|
773
|
+
provide additional links from a resource subject to synchronization to
|
|
774
|
+
related resources, including:
|
|
775
|
+
<ul>
|
|
776
|
+
<li><b>Alternate Content Transfer</b> -- The default mechanisms by which a Destination obtains
|
|
777
|
+
content for a resource are to issue an HTTP GET against its URI found
|
|
778
|
+
in a Resource List or Change List, or to unpack packages obtained via a
|
|
779
|
+
Resource Dump or Change Dump. However, additional approaches may also be supported.
|
|
780
|
+
For example, a Source may prefer, for synchronization purposes, that
|
|
781
|
+
content be obtained from a mirror server and hence from a different
|
|
782
|
+
URI. Also, a Source may allow obtaining only the changes that a
|
|
783
|
+
resource underwent, instead of the entire changed resource.
|
|
784
|
+
This may be desirable when the resource size is considerable and/or the
|
|
785
|
+
frequency of changes high. Such an Alternate Content Transfer approach
|
|
786
|
+
is expressed by means of a link from the resource to another resource that
|
|
787
|
+
makes the content available in an alternate way. It is possible that certain
|
|
788
|
+
Destinations do not recognize a specific Alternate Content Transfer approach,
|
|
789
|
+
in which case ignoring the link and dereferencing the resource's URI remains
|
|
790
|
+
the fallback approach.</li>
|
|
791
|
+
<li><b>Resources and Metadata about Resources</b> -- Cases exist where both resources and
|
|
792
|
+
metadata about resources must be synchronized, for example, a collection of scientific
|
|
793
|
+
publications and metadata describing each. From the ResourceSync perspective, both the
|
|
794
|
+
resource and the metadata about it are regarded as resources with distinct URIs that
|
|
795
|
+
are subject to synchronization. Their inter-relationship is expressed by means of links
|
|
796
|
+
with appropriate relation types.</li>
|
|
797
|
+
<li><b>Prior Versions of Resources</b> -- In some cases a Destination requires a copy of
|
|
798
|
+
each version of a resource, not just the most recent one.
|
|
799
|
+
A Source may support discovery and access to prior resource versions through links.
|
|
800
|
+
Three approaches are provided, one based on linking to
|
|
801
|
+
resource versions, and two that leverage features of the
|
|
802
|
+
<a href="#ref-memento">Memento</a> protocol for time-based
|
|
803
|
+
access to resource states.</li>
|
|
804
|
+
</ul>
|
|
805
|
+
</li>
|
|
806
|
+
</ul>
|
|
807
|
+
|
|
808
|
+
<div class="image">
|
|
809
|
+
<a name="fig_source_perspective"></a>
|
|
810
|
+
<img alt="ResourceSync Source Perspective" src="img/resync_source_perspective.png"/>
|
|
811
|
+
<p class="caption">Figure 1: ResourceSync Source perspective of resource description</p>
|
|
812
|
+
</div>
|
|
813
|
+
|
|
814
|
+
<div class="image">
|
|
815
|
+
<a name="fig_source_perspective"></a>
|
|
816
|
+
<!--FIXME-->
|
|
817
|
+
<p class="caption">Figure 2: ResourceSync Source perspective of change description</p>
|
|
818
|
+
</div>
|
|
819
|
+
|
|
820
|
+
<h3>5.2 <a name="DestPers">Destination Perspective</a></h3>
|
|
821
|
+
|
|
822
|
+
<p>From the perspective of a <b>Destination</b>, three key processes are enabled by the ResourceSync capabilities; <a href="#fig_destination_perspective">Figure 3</a>
|
|
823
|
+
provides an overview:</p>
|
|
824
|
+
|
|
825
|
+
<ul>
|
|
826
|
+
<li><b>Baseline Synchronization</b> -- In order to become synchronized with
|
|
827
|
+
a Source, the Destination must make an initial copy of the Source's data.
|
|
828
|
+
A Destination may obtain the Resource List that conveys the URIs of
|
|
829
|
+
the Source's resources, and subsequently dereference those URIs one by one.
|
|
830
|
+
A Destination may also obtain a Resource Dump that conveys the URIs of one
|
|
831
|
+
or more content packages each of which contains bitstreams associated
|
|
832
|
+
with the Source's resources. A Destination may dereference those URIs
|
|
833
|
+
and subsequently unpack the retrieved content packages, guided by the
|
|
834
|
+
contained Resource Dump Manifest.
|
|
835
|
+
</li>
|
|
836
|
+
<li><b>Incremental Synchronization</b> -- A Destination may remain in
|
|
837
|
+
sync with a Source by repeatedly performing a Baseline Synchronization.
|
|
838
|
+
To increase efficiency and decrease latency, a
|
|
839
|
+
Source may communicate information about changes to its resources via Change Lists.
|
|
840
|
+
This allows a Destination to obtain up-to-date content by dereferencing the
|
|
841
|
+
URIs of newly created and updated resources listed in the Change List.
|
|
842
|
+
It also allows a Destination to remove its copies of deleted resources, if needed.
|
|
843
|
+
A Source may also make a Change Dump available that points at one or more packages,
|
|
844
|
+
each of which contains bitstreams that correspond to the state of resources after they changed.
|
|
845
|
+
In this case the Destination first obtains the Change Dump, then obtains the
|
|
846
|
+
package(s) by dereferencing the URI(s) listed in the Change Dump, and
|
|
847
|
+
subsequently unpacks those, guided by the contained Change Dump Manifest.
|
|
848
|
+
</li>
|
|
849
|
+
<li><b>Audit</b> -- In order to verify whether it is in sync
|
|
850
|
+
with the Source, a Destination must be able to check that the content
|
|
851
|
+
it obtained matches the current resources hosted by the Source both regarding coverage and accuracy. This requires an up-to-date
|
|
852
|
+
list of resources hosted by the Source, which may be compiled on the basis of a Resource List and Change Lists. It also requires these Lists to contain metadata
|
|
853
|
+
per resource that characterizes its most recent state, such
|
|
854
|
+
as last modification time, length, and content-based hash.
|
|
855
|
+
</li>
|
|
856
|
+
</ul>
|
|
857
|
+
|
|
858
|
+
<div class="image">
|
|
859
|
+
<a name="fig_destination_perspective"></a>
|
|
860
|
+
<img alt="ResourceSync Destination Perspective" src="img/resync_destination_perspective.png"/>
|
|
861
|
+
<p class="caption">Figure 3: ResourceSync Destination perspective</p>
|
|
862
|
+
</div>
|
|
863
|
+
|
|
864
|
+
<h3>5.3 <a name="Summary">Summary</a></h3>
|
|
865
|
+
|
|
866
|
+
<p>
|
|
867
|
+
<a href="#tab_1">Table 1</a> provides a summary of
|
|
868
|
+
<a href="#SyncProcesses">Section 5</a>. The table lists Destination processes
|
|
869
|
+
as columns and Source capabilities as rows, with cells indicating the
|
|
870
|
+
applicability of a capability for a given process.
|
|
871
|
+
</p>
|
|
872
|
+
|
|
873
|
+
<!--TABLE:tab_1.xml-->
|
|
874
|
+
<a name="tab_1"></a>
|
|
875
|
+
<table class="capability-table" summary="Source Capabilities versus
|
|
876
|
+
Destination Processes">
|
|
877
|
+
<tbody><tr class="top">
|
|
878
|
+
<th>Source Capabilities</th><th colspan="3">Destination Processes</th>
|
|
879
|
+
</tr>
|
|
880
|
+
<tr class="top">
|
|
881
|
+
<th> </th><th>Baseline Synchronization</th><th>Incremental Synchronization</th><th>Audit</th>
|
|
882
|
+
</tr>
|
|
883
|
+
<tr class="odd">
|
|
884
|
+
<td class="scap"><a href="#SourceDesc">Describing the Source</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
885
|
+
</tr>
|
|
886
|
+
<tr class="odd">
|
|
887
|
+
<td class="scap"><a href="#CapabilityList">Advertising Capabilities</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
888
|
+
</tr>
|
|
889
|
+
<tr class="odd">
|
|
890
|
+
<td class="scap"><a href="#DescResources">Describing Resources</a></td><td colspan="3" class="sync"> </td><!--td class="sync"> </td><td class="audit"> </td-->
|
|
891
|
+
</tr>
|
|
892
|
+
<tr class="even">
|
|
893
|
+
<td class="scap"> <a href="#ResourceList">Resource List</a></td><td class="sync">X</td><td class="sync"> </td><td class="audit">X</td>
|
|
894
|
+
</tr>
|
|
895
|
+
<tr class="odd">
|
|
896
|
+
<td class="scap"><a href="#PackResources">Packaging Resources</a></td><td colspan="3" class="sync"> </td><!--td class="sync"> </td><td class="audit"> </td-->
|
|
897
|
+
</tr>
|
|
898
|
+
<tr class="even">
|
|
899
|
+
<td class="scap"> <a href="#ResourceDump">Resource Dump</a></td><td class="sync">X</td><td class="sync"> </td><td class="audit"></td>
|
|
900
|
+
</tr>
|
|
901
|
+
<tr class="odd">
|
|
902
|
+
<td class="scap"><a href="#DesChanges">Describing Changes</a></td><td colspan="3" class="sync"> </td><!--td class="sync"> </td><td class="audit"> </td-->
|
|
903
|
+
</tr>
|
|
904
|
+
<tr class="even">
|
|
905
|
+
<td class="scap"> <a href="#ChangeList">Change List</a></td><td class="sync"> </td><td class="sync">X</td><td class="audit">X</td>
|
|
906
|
+
</tr>
|
|
907
|
+
<tr class="odd">
|
|
908
|
+
<td class="scap"><a href="#PackChanges">Packaging Changes</a></td><td colspan="3" class="sync"> </td><!--td class="sync"> </td><td class="audit"> </td-->
|
|
909
|
+
</tr>
|
|
910
|
+
<tr class="even">
|
|
911
|
+
<td class="scap"> <a href="#ChangeDump">Change Dump</a></td><td class="sync"> </td><td class="sync">X</td><td class="audit"> </td>
|
|
912
|
+
</tr>
|
|
913
|
+
<tr class="odd">
|
|
914
|
+
<td class="scap"><a href="#LinkRelRes">Linking to Related Resources</a></td><td colspan="3" class="sync"> </td><!--td class="sync"> </td><td class="audit"> </td-->
|
|
915
|
+
</tr>
|
|
916
|
+
<tr class="even">
|
|
917
|
+
<td class="scap"> <a href="#MirCon">Mirrored Content</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
918
|
+
</tr>
|
|
919
|
+
<tr class="even">
|
|
920
|
+
<td class="scap"> <a href="#AltRep">Alternate Representations</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
921
|
+
</tr>
|
|
922
|
+
<tr class="even">
|
|
923
|
+
<td class="scap"> <a href="#PatchCon">Patching Content</a></td><td class="sync"> </td><td class="sync">X</td><td class="audit">X</td>
|
|
924
|
+
</tr>
|
|
925
|
+
<tr class="even">
|
|
926
|
+
<td class="scap"> <a href="#ResMDLinking">Resources and Metadata about Resources</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
927
|
+
</tr>
|
|
928
|
+
<tr class="even">
|
|
929
|
+
<td class="scap"> <a href="#ResVers">Prior Versions of Resources</a></td><td class="sync"></td><td class="sync">X</td><td class="audit">X</td>
|
|
930
|
+
</tr>
|
|
931
|
+
<tr class="even">
|
|
932
|
+
<td class="scap"> <a href="#ColMem">Collection Membership</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
933
|
+
</tr>
|
|
934
|
+
<tr class="even">
|
|
935
|
+
<td class="scap"> <a href="#RePub">Republishing Resources</a></td><td class="sync">X</td><td class="sync">X</td><td class="audit">X</td>
|
|
936
|
+
</tr>
|
|
937
|
+
</tbody></table>
|
|
938
|
+
<p class="caption">Table 1: Source capabilities versus Destination processes</p>
|
|
939
|
+
<!--/TABLE:tab_1.xml-->
|
|
940
|
+
|
|
941
|
+
|
|
942
|
+
<h2>6. <a name="FrameworkOrg">Framework Organization</a></h2>
|
|
943
|
+
|
|
944
|
+
<h3>6.1 <a name="Structure">Structure</a></h3>
|
|
945
|
+
<p>
|
|
946
|
+
All capabilities in the ResourceSync framework are implemented on the basis of the
|
|
947
|
+
<code><urlset></code> and <code><sitemapindex></code>
|
|
948
|
+
Sitemap document formats.
|
|
949
|
+
<a href="#fig_framework_structure">Figure 4: ResourceSync framework structure</a>,
|
|
950
|
+
depicts the overall structure of the set of documents that is used:
|
|
951
|
+
</p>
|
|
952
|
+
|
|
953
|
+
<ul>
|
|
954
|
+
<li>
|
|
955
|
+
At the top of the picture is the mandatory Source Description. It is a
|
|
956
|
+
Destination's typical entry point to learn about a Source's ResourceSync
|
|
957
|
+
implementation. The Source Description enumerates all Capability Lists
|
|
958
|
+
offered by the Source, one Capability List per set of resources.
|
|
959
|
+
If the Source only offers one set of resources, the ResourceSync
|
|
960
|
+
Description contains a single pointer.
|
|
961
|
+
A Source Description is expressed as a <code><urlset></code>
|
|
962
|
+
document and, per Capability List, a <code><url></code> element
|
|
963
|
+
is introduced. The <code><loc></code> child element of <code><url></code>
|
|
964
|
+
contains the URI of the Capability List, and the <code>capabilitylist</code> value for
|
|
965
|
+
the <code>capability</code> attribute of the <code><rs:md></code>
|
|
966
|
+
child element of <code><url></code>
|
|
967
|
+
makes clear that the URI is that of a Capability List.
|
|
968
|
+
</li>
|
|
969
|
+
<li>A Capability List enumerates all capabilities supported for a set of the Source's resources.
|
|
970
|
+
The capabilities defined in this ResourceSync specification are
|
|
971
|
+
Resource List, Change List, Resource Dump, and Change Dump. Additional capabilities may be defined
|
|
972
|
+
in other specifications.
|
|
973
|
+
A Capability List is expressed as a <code><urlset></code>
|
|
974
|
+
document and, for each supported capability, a <code><url></code> element is introduced. The <code><loc></code>
|
|
975
|
+
child element of
|
|
976
|
+
<code><url></code> contains the URI of the document that implements a capability, and the type of capability is expressed
|
|
977
|
+
by means of the value of the <code>capability</code> attribute of the <code><rs:md></code>
|
|
978
|
+
child element of <code><url></code>, e.g., <code>resourcelist</code> for a Resource List.</li>
|
|
979
|
+
<li>A Resource List and a Change List point at resources. A representation of a resource
|
|
980
|
+
may be obtained by dereferencing its URI, listed as the value of the
|
|
981
|
+
<code><loc></code> child element of the <code><url></code> element
|
|
982
|
+
for the resource.</li>
|
|
983
|
+
<li>A Resource Dump and a Change Dump point at packages, each of which contains bitstreams
|
|
984
|
+
associated with resources, as well as a
|
|
985
|
+
Manifest that describes the bitstreams provided in the package.</li>
|
|
986
|
+
<li>The Manifest contained in a package of bitstreams is expressed as a <code><urlset></code> document. For each bitstream contained in the package, that document
|
|
987
|
+
contains a <code><url></code> element; the <code><loc></code> child element of <code><url></code> provides
|
|
988
|
+
the URI that corresponds to the bitstream, whereas the <code>path</code> attribute of the <code><rs:md></code> child element
|
|
989
|
+
of <code><url></code> provides the path of the bitstream in the package.</li>
|
|
990
|
+
|
|
991
|
+
<li>If a single document suffices to express a Source Description, a Resource List, a Change List etc.,
|
|
992
|
+
then the <code><urlset></code> document format is used.
|
|
993
|
+
If multiple documents are required, each is expressed using the <code><urlset></code> document format, and a
|
|
994
|
+
<code><sitemapindex></code> document is introduced as an index to point at all individual <code><urlset></code> documents.
|
|
995
|
+
As a result, the URI of, for example, a Resource List provided in a Capability List may be
|
|
996
|
+
either that of a <code><urlset></code> or a <code><sitemapindex></code> document.
|
|
997
|
+
The <code><urlset></code> or <code><sitemapindex></code> documents used for a specific capability
|
|
998
|
+
(e.g., Resource List) have the same value for the
|
|
999
|
+
<code>capability</code> attribute (e.g., <code>resourcelist</code>).</li>
|
|
1000
|
+
</ul>
|
|
1001
|
+
|
|
1002
|
+
<p>
|
|
1003
|
+
The Resource List branch of <a href="#fig_framework_structure">Figure 4</a> is fully compatible with the existing
|
|
1004
|
+
Sitemap specification, whereas the other branches are extensions introduced to support resource synchronization that
|
|
1005
|
+
leverage the Sitemap document formats.
|
|
1006
|
+
</p>
|
|
1007
|
+
|
|
1008
|
+
<div class="image">
|
|
1009
|
+
<a name="fig_framework_structure"></a>
|
|
1010
|
+
<img alt="ResourceSync Framework Structure" src="img/resync_structure.png"/>
|
|
1011
|
+
<p class="caption">Figure 4: ResourceSync framework structure</p>
|
|
1012
|
+
</div>
|
|
1013
|
+
|
|
1014
|
+
<h3>6.2 <a name="Navigation">Navigation</a></h3>
|
|
1015
|
+
|
|
1016
|
+
<p>The following mechanisms are introduced to support navigating the document
|
|
1017
|
+
hierarchy described in <a href="#Structure">Section 6.1</a>;
|
|
1018
|
+
they are illustrated in <a href="#fig_navigation_up">Figure 5</a> and
|
|
1019
|
+
<a href="#fig_navigation_down">Figure 6</a>:</p>
|
|
1020
|
+
<ul>
|
|
1021
|
+
<li>A link for upward navigation is provided by means of an <code><rs:ln></code> child element of the
|
|
1022
|
+
<code><urlset></code> or <code><sitemapindex></code> element of a document. This pointer has
|
|
1023
|
+
<code>up</code> as the value for the <code>rel</code> attribute, and the URI of the document that sits higher
|
|
1024
|
+
in the hierarchy is provided as the value of the <code>href</code> attribute. Following consecutive <code>up</code>
|
|
1025
|
+
links eventually leads to the Source Description.</li>
|
|
1026
|
+
<li>A link for navigation from a document to the index under which it resides, if one exists, is
|
|
1027
|
+
provided by means of an <code><rs:ln></code> child element of the
|
|
1028
|
+
<code><urlset></code> element of the document. This pointer has
|
|
1029
|
+
<code>index</code> as the value for the <code>rel</code> attribute, and the URI of the index document
|
|
1030
|
+
is provided as the value of the <code>href</code> attribute.</li>
|
|
1031
|
+
<li>A link for downward navigation is provided by the content of a <code><url></code> element:
|
|
1032
|
+
the URI of the document that sits lower in the hierarchy is provided as the value of its <code><loc></code>
|
|
1033
|
+
child element, and its type is conveyed as the value of the <code>capability</code> attribute of the
|
|
1034
|
+
<code><rs:md></code> child element.</li>
|
|
1035
|
+
</ul>
|
|
1036
|
+
|
|
1037
|
+
<div class="image">
|
|
1038
|
+
<a name="fig_navigation_up"></a>
|
|
1039
|
+
<img alt="ResourceSync Navigation Upwards" src="img/resync_navigation_up.png"/>
|
|
1040
|
+
<p class="caption">Figure 5: ResourceSync upwards navigation</p>
|
|
1041
|
+
</div>
|
|
1042
|
+
|
|
1043
|
+
<div class="image">
|
|
1044
|
+
<a name="fig_navigation_down"></a>
|
|
1045
|
+
<img alt="ResourceSync Navigation Downwards" src="img/resync_navigation_down.png"/>
|
|
1046
|
+
<p class="caption">Figure 6: ResourceSync downwards navigation</p>
|
|
1047
|
+
</div>
|
|
1048
|
+
|
|
1049
|
+
<h3>6.3 <a name="Discovery">Discovery</a></h3>
|
|
1050
|
+
|
|
1051
|
+
<h4>6.3.1 <a name="DiscoOverview">Overview</a></h4>
|
|
1052
|
+
|
|
1053
|
+
<p>ResourceSync provides three ways for a Destination to discover
|
|
1054
|
+
whether and how a Source supports ResourceSync: a Source-wide
|
|
1055
|
+
approach detailed in <a href="#wellknown">Section 6.3.2</a>, a
|
|
1056
|
+
resource-specific approach detailed in
|
|
1057
|
+
<a href="#disco_links">Section 6.3.3</a>, and an approach that
|
|
1058
|
+
leverages the existing practice of Sitemap discovery via the
|
|
1059
|
+
<code>robots.txt</code> file described in <a href="#robots">Section 6.3.4</a>.
|
|
1060
|
+
All approaches are summarized in <a href="#fig_discovery">Figure 7</a>.
|
|
1061
|
+
</p>
|
|
1062
|
+
|
|
1063
|
+
<div class="image">
|
|
1064
|
+
<a name="fig_discovery"></a>
|
|
1065
|
+
<img alt="ResourceSync Discovery" src="img/resync_discovery.png"/>
|
|
1066
|
+
<p class="caption">Figure 7: Discovery of Source Description and Capability List</p>
|
|
1067
|
+
</div>
|
|
1068
|
+
|
|
1069
|
+
<h4>6.3.2 <a name="wellknown">ResourceSync Well-Known URI</a></h4>
|
|
1070
|
+
|
|
1071
|
+
<p>
|
|
1072
|
+
A Source must publish a Source Description, such as the one shown in
|
|
1073
|
+
<a href="#ex_7">Example 7</a>, and it should be published at the
|
|
1074
|
+
well-known URI [<a href="#ref-rfc5785">RFC 5785</a>]
|
|
1075
|
+
<code>/.well-known/resourcesync</code> as defined here.
|
|
1076
|
+
The Source Description document enumerates a Source's Capability Lists
|
|
1077
|
+
and as such is an appropriate entry
|
|
1078
|
+
point for Destinations interested in understanding a Source's capabilities.
|
|
1079
|
+
</p>
|
|
1080
|
+
|
|
1081
|
+
<h4>6.3.3 <a name="disco_links">Links</a></h4>
|
|
1082
|
+
|
|
1083
|
+
<p>
|
|
1084
|
+
A Capability List may be made discoverable by means of links provided either
|
|
1085
|
+
in an HTML document [<a href="#ref-html-links">HTML Links</a>,
|
|
1086
|
+
<a href="#ref-xhtml-links">XHTML Links</a>] or in an
|
|
1087
|
+
HTTP Link header [<a href="#ref-rfc5988">RFC 5988</a>].
|
|
1088
|
+
</p>
|
|
1089
|
+
<p>
|
|
1090
|
+
In order to include a discovery link in an HTML document,
|
|
1091
|
+
a <code><link></code> element is introduced in the <code><head></code>
|
|
1092
|
+
of the document that points to a Capability List.
|
|
1093
|
+
This <code><link></code> must have a <code>rel</code> attribute
|
|
1094
|
+
with a value of <code>resourcesync</code>.
|
|
1095
|
+
The Capability List that is made discoverable in this way must pertain to
|
|
1096
|
+
the resource that provides the link. This means that
|
|
1097
|
+
the resource must be covered by the capabilities listed in the linked Capability List.
|
|
1098
|
+
<a href="#ex_9">Example 9</a> shows the structure of a webpage that contains a
|
|
1099
|
+
link to a Capability List.
|
|
1100
|
+
</p>
|
|
1101
|
+
|
|
1102
|
+
<p>
|
|
1103
|
+
As shown in <a href="#ex_6">Example 6</a> the Source Description can
|
|
1104
|
+
be discovered from the Capability List by following the
|
|
1105
|
+
link provided in the <code><rs:ln></code> element with the relation type <code>up</code>.
|
|
1106
|
+
</p>
|
|
1107
|
+
<a name="ex_9"></a>
|
|
1108
|
+
<div class="exampleInner">
|
|
1109
|
+
<pre><html>
|
|
1110
|
+
<head>
|
|
1111
|
+
<span class="rs"><link rel="resourcesync"
|
|
1112
|
+
href="http://www.example.com/dataset1/capabilitylist.xml"/></span>
|
|
1113
|
+
...
|
|
1114
|
+
</head>
|
|
1115
|
+
<body>...</body>
|
|
1116
|
+
</html>
|
|
1117
|
+
</pre>
|
|
1118
|
+
</div>
|
|
1119
|
+
<p class="caption">Example 9: Discovery by means of an HTML link</p>
|
|
1120
|
+
|
|
1121
|
+
<p>
|
|
1122
|
+
A Capability List may also be made discoverable by means of an HTTP
|
|
1123
|
+
Link header that may be included with a representation of a resource of any
|
|
1124
|
+
content-type. In order to do so, a link is introduced in the HTTP Link header.
|
|
1125
|
+
The target of this link is the URI of a Capability List and the value of
|
|
1126
|
+
its <code>rel</code> attribute is <code>resourcesync</code>. The Capability
|
|
1127
|
+
List that is made discoverable in this way must pertain to the resource that
|
|
1128
|
+
provides the link. This means that the resource must be covered by the
|
|
1129
|
+
capabilities listed in the linked Capability List. <a href="#ex_10">Example 10</a>
|
|
1130
|
+
shows an excerpt of an HTTP response header that illustrates this approach.
|
|
1131
|
+
</p>
|
|
1132
|
+
|
|
1133
|
+
<p>
|
|
1134
|
+
As shown in <a href="#ex_6">Example 6</a> the Source Description can be
|
|
1135
|
+
discovered from the Capability List by following the link provided in the
|
|
1136
|
+
<code><rs:ln></code> element with the relation type <code>up</code>.
|
|
1137
|
+
</p>
|
|
1138
|
+
|
|
1139
|
+
<a name="ex_10"></a>
|
|
1140
|
+
<div class="exampleInner">
|
|
1141
|
+
<pre>HTTP/1.1 200 OK
|
|
1142
|
+
Date: Thu, 21 Jan 2010 00:02:12 GMT
|
|
1143
|
+
Server: Apache
|
|
1144
|
+
<span class="rs">Link: <http://www.example.com/dataset1/capabilitylist.xml>;
|
|
1145
|
+
rel="resourcesync"</span>
|
|
1146
|
+
...
|
|
1147
|
+
</pre>
|
|
1148
|
+
</div>
|
|
1149
|
+
<p class="caption">Example 10: Discovery by means of an HTTP link</p>
|
|
1150
|
+
|
|
1151
|
+
|
|
1152
|
+
<h4>6.3.4 <a name="robots">robots.txt</a></h4>
|
|
1153
|
+
<p>
|
|
1154
|
+
A Resource List is a Sitemap and hence may be made discoverable via the
|
|
1155
|
+
established approach of adding a <code>Sitemap</code> directive to a
|
|
1156
|
+
Source's <code>robots.txt</code> file that has the URI of the Resource
|
|
1157
|
+
List as its value. If a Source supports multiple sets of resources,
|
|
1158
|
+
multiple directives may be added, one for each Resource List associated
|
|
1159
|
+
with a specific set of resources. In case a Source supports both regular
|
|
1160
|
+
Sitemaps and ResourceSync Sitemaps (Resource Lists) they may be
|
|
1161
|
+
made discoverable, again, by including multiple <code>Sitemap</code>
|
|
1162
|
+
directives as shown in <a href="#ex_11">Example 11</a>.</p>
|
|
1163
|
+
|
|
1164
|
+
<p>Once a Resource List for a set of resources has been discovered
|
|
1165
|
+
in this manner, the corresponding Capability List can be discovered
|
|
1166
|
+
by following a link with the <code>up</code> relation type provided
|
|
1167
|
+
in the Resource List. Next, the Source Description can be discovered
|
|
1168
|
+
by following yet another link with the <code>up</code>
|
|
1169
|
+
relation type provided in the Capability List.
|
|
1170
|
+
</p>
|
|
1171
|
+
|
|
1172
|
+
<a name="ex_11"></a>
|
|
1173
|
+
<div class="exampleInner">
|
|
1174
|
+
<pre>User-agent: *
|
|
1175
|
+
Disallow: /cgi-bin/
|
|
1176
|
+
Disallow: /tmp/
|
|
1177
|
+
<span class="rs">Sitemap: http://example.com/dataset1/resourcelist.xml</span>
|
|
1178
|
+
</pre>
|
|
1179
|
+
</div>
|
|
1180
|
+
<p class="caption">Example 11: A <code>robots.txt</code> file that points at a Resource List</p>
|
|
1181
|
+
|
|
1182
|
+
|
|
1183
|
+
<h2>7. <a name="DocumentFormats">Sitemap Document Formats</a></h2>
|
|
1184
|
+
|
|
1185
|
+
<p>
|
|
1186
|
+
In order to convey information pertaining to resources in the ResourceSync framework,
|
|
1187
|
+
the Sitemap (root element <code><urlset></code>) and Sitemap index (root
|
|
1188
|
+
element <code><sitemapindex></code>) document formats introduced by the
|
|
1189
|
+
<a href="#ref-sitemaps">Sitemap protocol</a> are used for a variety of purposes.
|
|
1190
|
+
The <code><sitemapindex></code> document format is used when it is necessary to
|
|
1191
|
+
group multiple documents of the <code><urlset></code> format.
|
|
1192
|
+
The ResourceSync framework follows community-defined limits for when to
|
|
1193
|
+
publish multiple documents of the <code><urlset></code> format.
|
|
1194
|
+
At time of publication of this specification, the limit is 50,000 items
|
|
1195
|
+
per document and a document size of 50 MB.
|
|
1196
|
+
</p>
|
|
1197
|
+
|
|
1198
|
+
<p>
|
|
1199
|
+
The document formats, as well as their ResourceSync extension elements, are
|
|
1200
|
+
shown in <a href="#tab_2">Table 2</a>. The <code><rs:md></code>
|
|
1201
|
+
and <code><rs:ln></code> elements are introduced to express metadata
|
|
1202
|
+
and links, respectively.
|
|
1203
|
+
Both are in the ResourceSync XML Namespace and may have attributes.
|
|
1204
|
+
The attributes of these elements defined by ResourceSync are listed in
|
|
1205
|
+
<a href="#elem_intro_tab">Table 3</a> and detailed below. As shown in
|
|
1206
|
+
the examples, these attributes must not have an XML Namespace prefix.
|
|
1207
|
+
The <code><rs:ln></code> element as well as several of the
|
|
1208
|
+
ResourceSync attributes are based upon other specifications and in those
|
|
1209
|
+
cases inherit the semantics defined there; the "Specification" column of
|
|
1210
|
+
<a href="#elem_intro_tab">Table 3</a> refers to those specifications.
|
|
1211
|
+
Communities may introduce additional attributes when needed but must use
|
|
1212
|
+
an XML Namespace other than that of ResourceSync and must appropriately use
|
|
1213
|
+
namespace prefixes for those attributes.
|
|
1214
|
+
</p>
|
|
1215
|
+
|
|
1216
|
+
<a name="tab_2"></a>
|
|
1217
|
+
<table class="elem_intro-table" summary="Sitemap document formats">
|
|
1218
|
+
<tbody><tr class="top">
|
|
1219
|
+
<th>Sitemap</th><th>Sitemap Index</th>
|
|
1220
|
+
</tr>
|
|
1221
|
+
<tr class="even">
|
|
1222
|
+
<td class="left">
|
|
1223
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1224
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1225
|
+
<span class="rs">xmlns:rs="http://www.openarchives.org/rs/terms/"</span>>
|
|
1226
|
+
<span class="rs"><rs:md /></span>
|
|
1227
|
+
<span class="rs"><rs:ln /></span>
|
|
1228
|
+
<url>
|
|
1229
|
+
<loc />
|
|
1230
|
+
<lastmod />
|
|
1231
|
+
<span class="rs"><rs:md /></span>
|
|
1232
|
+
<span class="rs"><rs:ln /></span>
|
|
1233
|
+
</url>
|
|
1234
|
+
<url>
|
|
1235
|
+
...
|
|
1236
|
+
</url>
|
|
1237
|
+
</urlset>
|
|
1238
|
+
</pre>
|
|
1239
|
+
</td>
|
|
1240
|
+
<td class="left">
|
|
1241
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1242
|
+
<sitemapindex xmlns="..."
|
|
1243
|
+
<span class="rs">xmlns:rs="..."</span>>
|
|
1244
|
+
<span class="rs"><rs:md /></span>
|
|
1245
|
+
<span class="rs"><rs:ln /></span>
|
|
1246
|
+
<sitemap>
|
|
1247
|
+
<loc />
|
|
1248
|
+
<lastmod />
|
|
1249
|
+
<span class="rs"><rs:md /></span>
|
|
1250
|
+
<span class="rs"><rs:ln /></span>
|
|
1251
|
+
</sitemap>
|
|
1252
|
+
<sitemap>
|
|
1253
|
+
...
|
|
1254
|
+
</sitemap>
|
|
1255
|
+
</sitemapindex>
|
|
1256
|
+
</pre>
|
|
1257
|
+
</td>
|
|
1258
|
+
</tr>
|
|
1259
|
+
</tbody></table>
|
|
1260
|
+
<p class="caption">Table 2: The Sitemap document formats including the ResourceSync extensions</p>
|
|
1261
|
+
|
|
1262
|
+
<p>The overall structure of the ResourceSync documents is as follows:</p>
|
|
1263
|
+
|
|
1264
|
+
<p><code><urlset></code> or <code><sitemapindex></code> -- These
|
|
1265
|
+
elements are the root elements of ResourceSync documents; this specification
|
|
1266
|
+
adds one mandatory and one optional child element to the child elements of
|
|
1267
|
+
the Sitemap document formats:</p>
|
|
1268
|
+
<ul>
|
|
1269
|
+
<li><code><rs:md></code> -- In this context, the element conveys information about the document itself. Its use is
|
|
1270
|
+
mandatory and it may have the following attributes:
|
|
1271
|
+
<ul>
|
|
1272
|
+
<li><code>at</code> -- This attribute is used for Resource Lists, Resource List Indexes,
|
|
1273
|
+
Resource Dumps, Resource Dump Indexes, and Resource Dump Manifests; it is
|
|
1274
|
+
not used for Change Lists, Change List Indexes, Change Dumps, Change Dump
|
|
1275
|
+
Indexes, and Change Dump Manifests. Required use of the attribute is detailed in the
|
|
1276
|
+
sections describing the respective documents and summarized in <a href="#TimeAttributeReqs">Appendix A</a>.
|
|
1277
|
+
The <code>at</code> attribute conveys the datetime at which the process of taking
|
|
1278
|
+
a snapshot of resources for their inclusion in the document to which the
|
|
1279
|
+
attribute pertains started.
|
|
1280
|
+
It thus provides a guarantee that each resource state represented in the document is
|
|
1281
|
+
the result of all changes to the resource at least up until the
|
|
1282
|
+
datetime expressed as the value of the <code>at</code> attribute.
|
|
1283
|
+
The attribute value is expressed as a <a href="#w3c-datetime">W3C Datetime</a> and the
|
|
1284
|
+
use of a complete date and time expressed in UTC using the format <code>YYYY-MM-DDThh:mm:ss[.s]Z</code> is recommended.
|
|
1285
|
+
The attribute represents the time of a snapshot
|
|
1286
|
+
such as t1, t2, t3, and t4 of <a href="#fig_source_perspective">Figure 1</a>.
|
|
1287
|
+
</li>
|
|
1288
|
+
<li><code>capability</code> -- This attribute is mandatory in all ResourceSync documents. The value of the attribute conveys the nature of the document,
|
|
1289
|
+
e.g., whether the document is a Resource List, a Change List, a Manifest, etc.
|
|
1290
|
+
Defined values are <code>resourcelist</code>, <code>changelist</code>, <code>resourcedump</code>, <code>changedump</code>, <code>resourcedump-manifest</code>,
|
|
1291
|
+
<code>changedump-manifest</code>, <code>capabilitylist</code>, and <code>description</code>.
|
|
1292
|
+
</li>
|
|
1293
|
+
<li><code>completed</code> -- This optional attribute is used for Resource Lists,
|
|
1294
|
+
Resource List Indexes,
|
|
1295
|
+
Resource Dumps, Resource Dump Indexes, and Resource Dump Manifests; it is
|
|
1296
|
+
not used for Change Lists, Change List Indexes, Change Dumps, Change Dump
|
|
1297
|
+
Indexes, and Change Dump Manifests.
|
|
1298
|
+
The <code>completed</code> attribute conveys the datetime at which the process of taking
|
|
1299
|
+
a snapshot of resources for their inclusion in the document to which the attribute pertains completed.
|
|
1300
|
+
The combination of the datetimes provided in the <code>at</code> and <code>completed</code> attributes
|
|
1301
|
+
expresses an interval during which resources may have changed beyond the state they had at the datetime
|
|
1302
|
+
expressed in the <code>at</code> attribute.
|
|
1303
|
+
The attribute value for <code>completed</code> is expressed as a <a href="#w3c-datetime">W3C Datetime</a> and the
|
|
1304
|
+
use of a complete date and time expressed in UTC using the format <code>YYYY-MM-DDThh:mm:ss[.s]Z</code> is recommended.
|
|
1305
|
+
</li>
|
|
1306
|
+
<li><code>from</code> -- This attribute is used for Change Lists, Change List Indexes,
|
|
1307
|
+
Change Dumps, Change Dump Indexes, and Change Dump Manifests; it is not used
|
|
1308
|
+
for Resource Lists, Resource List Indexes, Resource Dumps, Resource Dump Indexes,
|
|
1309
|
+
and Resource Dump Manifests. Required use of the attribute is detailed in
|
|
1310
|
+
the sections describing the respective documents and summarized in
|
|
1311
|
+
<a href="#TimeAttributeReqs">Appendix A</a>.
|
|
1312
|
+
The attribute indicates that all changes that occurred to the set of resources at the Source
|
|
1313
|
+
since the datetime expressed (and up until the datetime expressed in the <code>until</code>
|
|
1314
|
+
attribute, if it exists) are included in the document to which the attribute pertains.
|
|
1315
|
+
The attribute value is expressed as a <a href="#w3c-datetime">W3C Datetime</a> and the
|
|
1316
|
+
use of a complete date and time expressed in UTC using the format <code>YYYY-MM-DDThh:mm:ss[.s]Z</code> is recommended.
|
|
1317
|
+
For example, the first Change List in
|
|
1318
|
+
<a href="#fig_source_perspective">Figure 2</a> would have a <code>from</code> value of t1, and the second Change List would have a <code>from</code>
|
|
1319
|
+
value of t3.
|
|
1320
|
+
</li>
|
|
1321
|
+
<li><code>until</code> -- This optional attribute is used for Change Lists, Change List Indexes, Change Dumps,
|
|
1322
|
+
Change Dump Indexes, and Change Dump Manifests; it is not used for Resource Lists,
|
|
1323
|
+
Resource List Indexes, Resource Dumps, Resource Dump Indexes, and Resource Dump Manifests.
|
|
1324
|
+
The attribute indicates that all changes that occurred to the set of resource at the Source
|
|
1325
|
+
up until the datetime expressed are included in the document to which the attribute pertains.
|
|
1326
|
+
<ul>
|
|
1327
|
+
<li>When a document carries the <code>until</code> attribute, this indicates that
|
|
1328
|
+
the document will not be updated anymore.</li>
|
|
1329
|
+
<li>When a change document does not carry the <code>until</code> attribute, any
|
|
1330
|
+
subsequent changes to the corresponding set of resources will cause the document
|
|
1331
|
+
to be updated.</li>
|
|
1332
|
+
</ul>
|
|
1333
|
+
The attribute value is expressed as a <a href="#w3c-datetime">W3C Datetime</a> and the
|
|
1334
|
+
use of a complete date and time expressed in UTC using the format <code>YYYY-MM-DDThh:mm:ss[.s]Z</code> is recommended.
|
|
1335
|
+
For example, the first Change List in <a href="#fig_source_perspective">Figure 2</a> would have an <code>until</code> value of t3 and the second
|
|
1336
|
+
Change List would have an <code>until</code> value of t5.
|
|
1337
|
+
</li>
|
|
1338
|
+
</ul>
|
|
1339
|
+
</li>
|
|
1340
|
+
<li>
|
|
1341
|
+
<code><rs:ln></code> -- A repeatable element used to support discovery of other
|
|
1342
|
+
documents by means of a link. Required use of the element is detailed in the sections
|
|
1343
|
+
that describe the documents in which <code><rs:ln></code> is used. It may have
|
|
1344
|
+
several attributes and the ones defined by ResourceSync are as follows:
|
|
1345
|
+
<ul>
|
|
1346
|
+
<li><code>href</code> -- A mandatory attribute to convey the URI of the other document.</li>
|
|
1347
|
+
<li><code>rel</code> -- A mandatory attribute to express a relationship. The following values are explicitly used in this specification:
|
|
1348
|
+
<ul>
|
|
1349
|
+
<li><code>describedby</code> -- for linking from a Capability List to a document that describes the set of resources
|
|
1350
|
+
covered by it, and from a Source Description to a document that describes the Source.</li>
|
|
1351
|
+
<li><code>up</code> -- for linking from a Capability List to the Source Description and from a
|
|
1352
|
+
document that conveys a capability, such as a Resource List, to the Capability List under which it resides.
|
|
1353
|
+
</li>
|
|
1354
|
+
<li><code>index</code> -- for linking from a document that conveys a capability (e.g., a Resource List)
|
|
1355
|
+
to a parent index document (e.g., a Resource List Index).</li>
|
|
1356
|
+
</ul>
|
|
1357
|
+
</li>
|
|
1358
|
+
</ul>
|
|
1359
|
+
</li>
|
|
1360
|
+
|
|
1361
|
+
<li><code><url></code> or <code><sitemap></code> -- The <code><urlset></code> element may have zero or more
|
|
1362
|
+
<code><url></code> child elements, and the
|
|
1363
|
+
<code><sitemapindex></code> element has zero or more <code><sitemap></code> child elements. Each such child element is used to convey information about
|
|
1364
|
+
a resource that plays a role in the ResourceSync framework. They may have the
|
|
1365
|
+
following child elements:
|
|
1366
|
+
<ul>
|
|
1367
|
+
<li><code><loc></code> -- A mandatory element that conveys the URI of the resource that plays a role in the ResourceSync framework.</li>
|
|
1368
|
+
<li><code><lastmod></code> -- An element that conveys the last modification time of the resource with the URI provided in <code><loc></code>,
|
|
1369
|
+
expressed as a <a href="#w3c-datetime">W3C Datetime</a> as described earlier in this section.
|
|
1370
|
+
Its use is mandatory in Change Lists and Change Dump Manifests, and optional in other documents.</li>
|
|
1371
|
+
<li><code><changefreq></code> -- An optional element that provides a hint about the change frequency
|
|
1372
|
+
of the resource with the URI provided in <code><loc></code>. Defined values are <code>always</code>, <code>hourly</code>,
|
|
1373
|
+
<code>daily</code>, <code>weekly</code>, <code>monthly</code>, <code>yearly</code>, and <code>never</code>.
|
|
1374
|
+
The value <code>always</code> should be used for resources that change each time they are accessed.
|
|
1375
|
+
The value <code>never</code> should be used for archived resources.</li>
|
|
1376
|
+
<li><code><rs:md></code> -- In this context, the element conveys metadata pertaining to the resource with the URI provided in <code><loc></code>.
|
|
1377
|
+
The element is not repeatable, and is mandatory for some documents and optional
|
|
1378
|
+
for others, as described in the appropriate sections. It may have several
|
|
1379
|
+
attributes and the ones defined by ResourceSync are as follows:
|
|
1380
|
+
<ul>
|
|
1381
|
+
<li><code>at</code> and <code>completed</code> -- The semantics and value
|
|
1382
|
+
of these attributes are as defined earlier in this section.
|
|
1383
|
+
They are only used for Resource List Indexes, Resource Dumps, and Resource Dump Indexes.
|
|
1384
|
+
Required use of the attributes is detailed in the sections describing the respective documents
|
|
1385
|
+
and summarized in <a href="#TimeAttributeReqs">Appendix A</a>.</li>
|
|
1386
|
+
<li><code>capability</code> -- This attribute is mandatory in Source Descriptions and Capability Lists.
|
|
1387
|
+
Its value indicates the nature of the resource identified by the URI
|
|
1388
|
+
in the <code><loc></code> element, e.g., a Resource List, a Change
|
|
1389
|
+
List, a Change Dump, etc. Values defined in this specification are
|
|
1390
|
+
<code>resourcelist</code>, <code>changelist</code>, <code>resourcedump</code>, <code>changedump</code>, and <code>capabilitylist</code>.</li>
|
|
1391
|
+
<li><code>change</code> -- The value of the attribute conveys the type of change
|
|
1392
|
+
that a resource underwent. Values defined in this specification are
|
|
1393
|
+
<code>created</code>, <code>updated</code>, and <code>deleted</code> to convey the creation, update, and deletion of a resource, respectively.
|
|
1394
|
+
This attribute is used in <a href="#ChangeList">Change Lists (Section 12.1)</a> and <a href="#ChangeDumpManifest">Change Dump Manifests (Section 13.2)</a>.</li>
|
|
1395
|
+
<li><code>encoding</code> -- The value of the attribute conveys what content codings have been applied to the resource. The value of the
|
|
1396
|
+
<code>encoding</code> attribute should be equal to the value of the <code>content-encoding</code> header in the HTTP response as defined in
|
|
1397
|
+
<a href="#ref-rfc2616">RFC 2616, Sec. 14.11</a>.</li>
|
|
1398
|
+
<li><code>from</code> and <code>until</code> -- The semantics and value
|
|
1399
|
+
of these attributes are as defined earlier in this section.
|
|
1400
|
+
They are only used for Change List Indexes, Change Dumps, and Change Dump Indexes.
|
|
1401
|
+
Required use of the attributes is detailed in the sections describing the respective documents
|
|
1402
|
+
and summarized in <a href="#TimeAttributeReqs">Appendix A</a>.</li>
|
|
1403
|
+
<li><code>hash</code> -- The value of the attribute conveys fixity information for a resource representation returned when the URI in <code><loc></code> is dereferenced.
|
|
1404
|
+
The attribute value is expressed in the form of a whitespace-delimited list of hash values.
|
|
1405
|
+
Each hash value is represented by a hex-encoded digest and is preceded by a token that identifies the utilized hash algorithm, e.g., <code>md5:</code>, <code>sha-256:</code>.</li>
|
|
1406
|
+
<li><code>length</code> -- The value of the attribute conveys the content length of a resource representation returned when the URI in <code><loc></code> is dereferenced.
|
|
1407
|
+
The value of the <code>length</code> attribute should be equal to the value of the <code>Content-Length</code> header in the HTTP response
|
|
1408
|
+
and must be computed as defined in <a href="#ref-rfc2616">RFC 2616, Sec. 4.4</a>.</li>
|
|
1409
|
+
|
|
1410
|
+
<li><code>path</code> -- The attribute is only used in
|
|
1411
|
+
<a href="#ResourceDumpManifest">Resource Dump Manifests (Section 11.2)</a> and
|
|
1412
|
+
<a href="#ChangeDumpManifest">Change Dump Manifests (Section 13.2)</a>.
|
|
1413
|
+
Its value conveys the file path of the bitstream associated with the URI in <code><loc></code> in the ZIP file. That is
|
|
1414
|
+
the relative file system path where the bitstream would reside if the ZIP were unpacked.</li>
|
|
1415
|
+
<li><code>type</code> -- The value of the attribute conveys the Media Type of a resource representation returned when the URI in
|
|
1416
|
+
<code><loc></code> is dereferenced.
|
|
1417
|
+
Registered values are listed in the <a href="#ref-iana-mime">IANA MIME Media Type registry</a>.</li>
|
|
1418
|
+
</ul>
|
|
1419
|
+
</li>
|
|
1420
|
+
<li><code><rs:ln></code> -- In this context, an optional and repeatable element used to link to resources related to the one with the
|
|
1421
|
+
URI provided in <code><loc></code>, such as
|
|
1422
|
+
a copy on a mirror site, a prior version of the resource, etc. (see
|
|
1423
|
+
Linking to Related Resources in <a href="#SourcePers">Section 5.1</a>).
|
|
1424
|
+
It may have several attributes and the ones defined by ResourceSync are as follows:
|
|
1425
|
+
<ul>
|
|
1426
|
+
<li><code>href</code> -- A mandatory attribute to convey the URI of the related resource.
|
|
1427
|
+
</li>
|
|
1428
|
+
<li><code>rel</code> -- A mandatory attribute to convey the relationship between the resource with the URI in <code><loc></code>
|
|
1429
|
+
and the one with the URI in <code>href</code>.
|
|
1430
|
+
Values for the <code>rel</code> attribute are listed in the document
|
|
1431
|
+
<a href="#ref-relationtypes">Relation Types Used in the ResourceSync
|
|
1432
|
+
Framework</a>. The ones featured in this specification are:
|
|
1433
|
+
<ul>
|
|
1434
|
+
<li><code>contents</code> -- for a link from an entry in a Resource Dump or Change Dump that points to a bitstream package
|
|
1435
|
+
to a Resource Dump Manifest or a Change Dump Manifest, respectively, for that bitstream package.</li>
|
|
1436
|
+
<li><code>duplicate</code> -- for a link to a resource's mirror location.</li>
|
|
1437
|
+
<li><code>alternate</code> and <code>canonical</code> -- for a link to an alternate representation of a resource.</li>
|
|
1438
|
+
<li><code>http://www.openarchives.org/rs/terms/patch</code> -- for a link to a resource that details the difference between the
|
|
1439
|
+
previous and current version of a resource.</li>
|
|
1440
|
+
<li><code>describedby</code> and <code>describes</code> -- for a link providing additional information about a resource.</li>
|
|
1441
|
+
<li><code>memento</code> and <code>timegate</code> -- for a link to access prior versions of a resource.</li>
|
|
1442
|
+
<li><code>collection</code> -- for a link that expresses collection membership.</li>
|
|
1443
|
+
<li><code>via</code> -- for a link that provides provenance information.</li>
|
|
1444
|
+
</ul>
|
|
1445
|
+
</li>
|
|
1446
|
+
<li><code>encoding</code>, <code>hash</code>, <code>length</code>,
|
|
1447
|
+
<code>modified</code>, <code>path</code>, <code>type</code> -- Optional
|
|
1448
|
+
attributes with meanings as described earlier in this section and
|
|
1449
|
+
pertaining to the related resource.</li>
|
|
1450
|
+
<li><code>pri</code> -- An optional attribute used to express a priority
|
|
1451
|
+
among links with the same relation type. The attribute value is an integer
|
|
1452
|
+
between 1 and 999,999, with a lower integer indicating a higher priority
|
|
1453
|
+
and the absence of the attribute indicating a value of 999,999.</li>
|
|
1454
|
+
</ul>
|
|
1455
|
+
</li>
|
|
1456
|
+
</ul>
|
|
1457
|
+
</li>
|
|
1458
|
+
</ul>
|
|
1459
|
+
|
|
1460
|
+
<p><a href="#elem_intro_tab">Table 3</a> lists the elements used in ResourceSync
|
|
1461
|
+
documents and for each shows the attributes defined by ResourceSync
|
|
1462
|
+
that may be used with them. The "Specification" column refers to the
|
|
1463
|
+
specification where elements or attributes were introduced that
|
|
1464
|
+
ResourceSync equivalents are based upon and inherit their semantics from.
|
|
1465
|
+
A mark in the "Representation" column for an attribute indicates
|
|
1466
|
+
that it should only be used when a specific representation of a resource is concerned,
|
|
1467
|
+
whereas a mark in the "Resource" column indicates it is usable
|
|
1468
|
+
for a resource in general. A <a href="resourcesync.xsd">W3C XML Schema</a>
|
|
1469
|
+
(available at <a href="resourcesync.xsd">http://www.niso.org/schemas/resourcesync</a>)
|
|
1470
|
+
is provided to validate the elements introduced by ResourceSync.</p>
|
|
1471
|
+
<!--FIXME - Link to local and remote schemas-->
|
|
1472
|
+
|
|
1473
|
+
<p>Relation types other than the ones listed above may be used in the
|
|
1474
|
+
ResourceSync Framework. Valid relation types must be registered in the
|
|
1475
|
+
<a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA Link Relation Type Registry</a>
|
|
1476
|
+
or expressed as URIs as specified in <a href="#ref-rfc5988">RFC 5988, Sec. 4.2</a>. The document
|
|
1477
|
+
<a href="#ref-relationtypes">Relation Types Used in the ResourceSync Framework</a> attempts to
|
|
1478
|
+
provide an up-to-date overview.</p>
|
|
1479
|
+
|
|
1480
|
+
<a name="elem_intro_tab"></a>
|
|
1481
|
+
<table class="elem_intro-table" summary="Elements used and sources of definitions">
|
|
1482
|
+
<tbody>
|
|
1483
|
+
<tr class="top">
|
|
1484
|
+
<th class="left">Element/Attribute</th><th>Specification</th><th>Resource</th><th>Representation</th>
|
|
1485
|
+
</tr>
|
|
1486
|
+
<tr class="top1">
|
|
1487
|
+
<td class="left"><b><code><urlset></code> or <code><sitemapindex></code></b></td><td><a href="#ref-sitemaps">Sitemap protocol</a></td><td></td><td></td>
|
|
1488
|
+
</tr>
|
|
1489
|
+
<tr class="top1">
|
|
1490
|
+
<td class="left"> <b><code><rs:md></code></b></td><td>This specification</td><td></td><td></td>
|
|
1491
|
+
</tr>
|
|
1492
|
+
<tr class="odd">
|
|
1493
|
+
<td class="left"> <code>at</code></td><td>This specification</td><td></td><td></td>
|
|
1494
|
+
</tr>
|
|
1495
|
+
<tr class="even">
|
|
1496
|
+
<td class="left"> <code>capability</code></td><td>This specification</td><td></td><td></td>
|
|
1497
|
+
</tr>
|
|
1498
|
+
<tr class="odd">
|
|
1499
|
+
<td class="left"> <code>completed</code></td><td>This specification</td><td></td><td></td>
|
|
1500
|
+
</tr>
|
|
1501
|
+
<tr class="even">
|
|
1502
|
+
<td class="left"> <code>from</code></td><td>This specification</td><td></td><td></td>
|
|
1503
|
+
</tr>
|
|
1504
|
+
<tr class="odd">
|
|
1505
|
+
<td class="left"> <code>until</code></td><td>This specification</td><td></td><td></td>
|
|
1506
|
+
</tr>
|
|
1507
|
+
<tr class="top1">
|
|
1508
|
+
<td class="left"> <b><code><rs:ln></code></b></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td></td>
|
|
1509
|
+
</tr>
|
|
1510
|
+
<tr class="odd">
|
|
1511
|
+
<td class="left"> <code>href</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td></td>
|
|
1512
|
+
</tr>
|
|
1513
|
+
<tr class="even">
|
|
1514
|
+
<td class="left"> <code>rel</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td></td>
|
|
1515
|
+
</tr>
|
|
1516
|
+
<tr class="top1">
|
|
1517
|
+
<td class="left"> <b><code><url></code> or <code><sitemap></code></b></td><td><a href="#ref-sitemaps">Sitemap protocol</a></td><td></td><td></td>
|
|
1518
|
+
</tr>
|
|
1519
|
+
<tr class="odd">
|
|
1520
|
+
<td class="left"> <code><loc></code></td><td><a href="#ref-sitemaps">Sitemap protocol</a></td><td></td><td></td>
|
|
1521
|
+
</tr>
|
|
1522
|
+
<tr class="even">
|
|
1523
|
+
<td class="left"> <code><lastmod></code></td><td><a href="#ref-sitemaps">Sitemap protocol</a></td><td></td><td></td>
|
|
1524
|
+
</tr>
|
|
1525
|
+
<tr class="odd">
|
|
1526
|
+
<td class="left"> <code><changefreq></code></td><td><a href="#ref-sitemaps">Sitemap protocol</a></td><td></td><td></td>
|
|
1527
|
+
</tr>
|
|
1528
|
+
<tr class="top1">
|
|
1529
|
+
<td class="left"> <b><code><rs:md></code></b></td><td>This specification</td><td></td><td></td>
|
|
1530
|
+
</tr>
|
|
1531
|
+
<tr class="odd">
|
|
1532
|
+
<td class="left"> <code>at</code></td><td>This specification</td><td></td><td></td>
|
|
1533
|
+
</tr>
|
|
1534
|
+
<tr class="even">
|
|
1535
|
+
<td class="left"> <code>capability</code></td><td>This specification</td><td></td><td></td>
|
|
1536
|
+
</tr>
|
|
1537
|
+
<tr class="odd">
|
|
1538
|
+
<td class="left"> <code>change</code></td><td>This specification</td><td>X</td><td>X</td>
|
|
1539
|
+
</tr>
|
|
1540
|
+
<tr class="even">
|
|
1541
|
+
<td class="left"> <code>completed</code></td><td>This specification</td><td></td><td></td>
|
|
1542
|
+
</tr>
|
|
1543
|
+
<tr class="odd">
|
|
1544
|
+
<td class="left"> <code>encoding</code></td><td><a href="#ref-rfc2616">RFC2616</a></td><td></td><td>X</td>
|
|
1545
|
+
</tr>
|
|
1546
|
+
<tr class="even">
|
|
1547
|
+
<td class="left"> <code>from</code></td><td>This specification</td><td></td><td></td>
|
|
1548
|
+
</tr>
|
|
1549
|
+
<tr class="odd">
|
|
1550
|
+
<td class="left"> <code>hash</code></td><td><a href="#ref-ale">Atom Link Extensions</a></td><td></td><td>X</td>
|
|
1551
|
+
</tr>
|
|
1552
|
+
<tr class="even">
|
|
1553
|
+
<td class="left"> <code>length</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td>X</td>
|
|
1554
|
+
</tr>
|
|
1555
|
+
<tr class="odd">
|
|
1556
|
+
<td class="left"> <code>path</code></td><td>This specification</td><td></td><td>X</td>
|
|
1557
|
+
</tr>
|
|
1558
|
+
<tr class="even">
|
|
1559
|
+
<td class="left"> <code>type</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td>X</td>
|
|
1560
|
+
</tr>
|
|
1561
|
+
<tr class="odd">
|
|
1562
|
+
<td class="left"> <code>until</code></td><td>This specification</td><td></td><td></td>
|
|
1563
|
+
</tr>
|
|
1564
|
+
<tr class="top1">
|
|
1565
|
+
<td class="left"> <b><code><rs:ln></code></b></td><td>This specification</td><td></td><td></td>
|
|
1566
|
+
</tr>
|
|
1567
|
+
<tr class="odd">
|
|
1568
|
+
<td class="left"> <code>encoding</code></td><td><a href="#ref-rfc2616">RFC2616</a></td><td></td><td>X</td>
|
|
1569
|
+
</tr>
|
|
1570
|
+
<tr class="even">
|
|
1571
|
+
<td class="left"> <code>hash</code></td><td><a href="#ref-ale">Atom Link Extensions</a></td><td></td><td>X</td>
|
|
1572
|
+
</tr>
|
|
1573
|
+
<tr class="odd">
|
|
1574
|
+
<td class="left"> <code>href</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td>X</td><td>X</td>
|
|
1575
|
+
</tr>
|
|
1576
|
+
<tr class="even">
|
|
1577
|
+
<td class="left"> <code>length</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td>X</td>
|
|
1578
|
+
</tr>
|
|
1579
|
+
<tr class="odd">
|
|
1580
|
+
<td class="left"> <code>modified</code></td><td><a href="#ref-ale">Atom Link Extensions</a></td><td>X</td><td>X</td>
|
|
1581
|
+
</tr>
|
|
1582
|
+
<tr class="even">
|
|
1583
|
+
<td class="left"> <code>path</code></td><td>This specification</td><td></td><td>X</td>
|
|
1584
|
+
</tr>
|
|
1585
|
+
<tr class="odd">
|
|
1586
|
+
<td class="left"> <code>pri</code></td><td><a href="#ref-rfc6249">RFC6249</a></td><td>X</td><td>X</td>
|
|
1587
|
+
</tr>
|
|
1588
|
+
<tr class="even">
|
|
1589
|
+
<td class="left"> <code>rel</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td>X</td><td>X</td>
|
|
1590
|
+
</tr>
|
|
1591
|
+
<tr class="odd">
|
|
1592
|
+
<td class="left"> <code>type</code></td><td><a href="#ref-rfc4287">RFC4287</a></td><td></td><td>X</td>
|
|
1593
|
+
</tr>
|
|
1594
|
+
</tbody></table>
|
|
1595
|
+
<p class="caption">Table 3: Elements and associated attributes defined for the ResourceSync documents</p>
|
|
1596
|
+
|
|
1597
|
+
|
|
1598
|
+
<h2>8. <a name="SourceDesc"></a>Describing the Source</h2>
|
|
1599
|
+
|
|
1600
|
+
<p>
|
|
1601
|
+
A <b>Source Description</b> is a mandatory document that enumerates the
|
|
1602
|
+
Capability Lists offered by a Source. Since a Source has one Capability
|
|
1603
|
+
List per set of resources that it distinguishes, the Source Description
|
|
1604
|
+
will enumerate as many Capability Lists as the Source has distinct sets
|
|
1605
|
+
of resources.
|
|
1606
|
+
</p>
|
|
1607
|
+
<p>
|
|
1608
|
+
The Source Description is based on the <code><urlset></code> format.
|
|
1609
|
+
It has the <code><urlset></code> root element and the following structure:
|
|
1610
|
+
</p>
|
|
1611
|
+
<ul>
|
|
1612
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code>
|
|
1613
|
+
must have a <code>capability</code> attribute that has a value of <code>description</code>.</li>
|
|
1614
|
+
<li>A recommended <code><rs:ln></code> child element of <code><urlset></code>
|
|
1615
|
+
with the relation type <code>describedby</code>
|
|
1616
|
+
points to a document that provides information about the Source.</li>
|
|
1617
|
+
<li>One <code><url></code> child element of <code><urlset></code>
|
|
1618
|
+
should be included for each Capability List offered by the Source. This
|
|
1619
|
+
element does not have attributes, but uses child elements to convey
|
|
1620
|
+
information about the Capability Lists. The <code><url></code>
|
|
1621
|
+
element has the following child elements:
|
|
1622
|
+
<ul>
|
|
1623
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the respective Capability List.</li>
|
|
1624
|
+
<li>An optional <code><rs:md></code> child element must have a <code>capability</code> attribute with a value of
|
|
1625
|
+
<code>capabilitylist</code>
|
|
1626
|
+
to convey that the URI points to a Capability List.</li>
|
|
1627
|
+
<li>A recommended <code><rs:ln></code> child element with a <code>describedby</code> relation type
|
|
1628
|
+
points to a document that describes the set of resources described by the Capability List.</li>
|
|
1629
|
+
</ul>
|
|
1630
|
+
</li>
|
|
1631
|
+
</ul>
|
|
1632
|
+
<p>
|
|
1633
|
+
The <code><lastmod></code> elements should be omitted from the Source Description unless the Source updates the
|
|
1634
|
+
Source Description every time it updates one of the Capability Lists.
|
|
1635
|
+
</p>
|
|
1636
|
+
<p>
|
|
1637
|
+
<a href="#ex_12">Example 12</a> shows a Source Description where the Source offers three Capability Lists.
|
|
1638
|
+
</p>
|
|
1639
|
+
<a name="ex_12"></a>
|
|
1640
|
+
<div class="exampleInner">
|
|
1641
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1642
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1643
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
1644
|
+
<rs:ln rel="describedby"
|
|
1645
|
+
href="http://example.com/info_about_source.xml"/>
|
|
1646
|
+
<rs:md <span class="rs">capability="description"</span>/>
|
|
1647
|
+
<url>
|
|
1648
|
+
<loc>http://example.com/capabilitylist1.xml</loc>
|
|
1649
|
+
<rs:md capability="capabilitylist"/>
|
|
1650
|
+
<rs:ln rel="describedby"
|
|
1651
|
+
href="http://example.com/info_about_set1_of_resources.xml"/>
|
|
1652
|
+
</url>
|
|
1653
|
+
<url>
|
|
1654
|
+
<loc>http://example.com/capabilitylist2.xml</loc>
|
|
1655
|
+
<rs:md capability="capabilitylist"/>
|
|
1656
|
+
<rs:ln rel="describedby"
|
|
1657
|
+
href="http://example.com/info_about_set2_of_resources.xml"/>
|
|
1658
|
+
</url>
|
|
1659
|
+
<url>
|
|
1660
|
+
<loc>http://example.com/capabilitylist3.xml</loc>
|
|
1661
|
+
<rs:md capability="capabilitylist"/>
|
|
1662
|
+
<rs:ln rel="describedby"
|
|
1663
|
+
href="http://example.com/info_about_set3_of_resources.xml"/>
|
|
1664
|
+
</url>
|
|
1665
|
+
</urlset>
|
|
1666
|
+
</pre>
|
|
1667
|
+
</div>
|
|
1668
|
+
<p class="caption">Example 12: A Source Description</p>
|
|
1669
|
+
|
|
1670
|
+
<p>
|
|
1671
|
+
If a Source needs to or chooses to publish multiple Source Descriptions, it must group them by means of a Source Description Index.
|
|
1672
|
+
</p>
|
|
1673
|
+
|
|
1674
|
+
|
|
1675
|
+
<h2>9. <a name="CapabilityList"></a>Advertising Capabilities</h2>
|
|
1676
|
+
|
|
1677
|
+
<p>
|
|
1678
|
+
A <b>Capability List</b> is a document that enumerates all capabilities supported by a
|
|
1679
|
+
Source for a specific set of resources. The Source defines which resources are
|
|
1680
|
+
part of the set of resources described by the Capability List.
|
|
1681
|
+
If there is more than one such set, then the Source must distinguish them with
|
|
1682
|
+
different capability lists. The choice of which resources are part of which set
|
|
1683
|
+
may derive from a variety of criteria, including media type, collection membership,
|
|
1684
|
+
change frequency, subject of the resource and many others.
|
|
1685
|
+
</p>
|
|
1686
|
+
<p>
|
|
1687
|
+
A Capability List points at the capability documents for its set of resources:
|
|
1688
|
+
Resource List (<a href="#DescResources">Section 10.1</a>),
|
|
1689
|
+
Resource Dump (<a href="#ResourceDump">Section 11.1</a>),
|
|
1690
|
+
Change List (<a href="#DesChanges">Section 12.1</a>), and
|
|
1691
|
+
Change Dump (<a href="#ChangeDump">Section 13.1</a>).
|
|
1692
|
+
A Capability List must only contain one entry per capability.
|
|
1693
|
+
</p>
|
|
1694
|
+
<p>
|
|
1695
|
+
Capabilities that are conveyed in the same Capability List uniformly apply to
|
|
1696
|
+
the set of resources covered by that Capability List. For example, if a
|
|
1697
|
+
Capability List enumerates a Resource List, a Resource Dump, and a Change List,
|
|
1698
|
+
then a given resource that appears in a Resource List must also appear in a
|
|
1699
|
+
Resource Dump, and changes to the resource must be conveyed in the Change List.
|
|
1700
|
+
</p>
|
|
1701
|
+
<p>
|
|
1702
|
+
The Capability List is based on the <code><urlset></code> format.
|
|
1703
|
+
It has the <code><urlset></code> root element and the following structure:
|
|
1704
|
+
</p>
|
|
1705
|
+
<ul>
|
|
1706
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
1707
|
+
<code>capability</code> attribute that has a value of <code>capabilitylist</code>.</li>
|
|
1708
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><urlset></code> with the relation type <code>up</code>
|
|
1709
|
+
points to the Source Description document that enumerates all Capability Lists offered by the Source.</li>
|
|
1710
|
+
<li>A recommended <code><rs:ln></code> child element of <code><urlset></code> with the relation type <code>describedby</code>
|
|
1711
|
+
points to a document that provides information about the set of resources covered by the Capability List.</li>
|
|
1712
|
+
<li>One <code><url></code> child element of <code><urlset></code> per capability offered by the Source. This element does not have attributes, but uses
|
|
1713
|
+
child elements to convey information about the capabilities. The <code><url></code> element has the following child elements:
|
|
1714
|
+
<ul>
|
|
1715
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the respective capability document.</li>
|
|
1716
|
+
<li>A mandatory <code><rs:md></code> child element must have a <code>capability</code> attribute to convey the type of the respective capability.</li>
|
|
1717
|
+
</ul>
|
|
1718
|
+
</li>
|
|
1719
|
+
</ul>
|
|
1720
|
+
<p>
|
|
1721
|
+
The <code><lastmod></code> elements should be omitted from the Capability List unless the Source updates the Capability List
|
|
1722
|
+
every time it updates one of the capability documents.
|
|
1723
|
+
</p>
|
|
1724
|
+
<p>
|
|
1725
|
+
<a href="#ex_13">Example 13</a> shows a Capability List where the Source offers four capabilities: a Resource List, a Resource Dump, a Change List,
|
|
1726
|
+
and a Change Dump. A Destination cannot determine from the Capability List whether a Source provides, for example, a Resource List Index or a single Resource List.
|
|
1727
|
+
The capability document must be downloaded to make this determination: a document with a <code><sitemapindex></code> root element is an index,
|
|
1728
|
+
a document with a <code><urlset></code> root element is not.
|
|
1729
|
+
</p>
|
|
1730
|
+
<a name="ex_13"></a>
|
|
1731
|
+
<div class="exampleInner">
|
|
1732
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1733
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1734
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
1735
|
+
<rs:ln rel="describedby"
|
|
1736
|
+
href="http://example.com/info_about_set1_of_resources.xml"/>
|
|
1737
|
+
<rs:ln <span class="rs">rel="up"</span>
|
|
1738
|
+
href="http://example.com/resourcesync_description.xml"/>
|
|
1739
|
+
<rs:md <span class="rs">capability="capabilitylist"</span>/>
|
|
1740
|
+
<url>
|
|
1741
|
+
<loc>http://example.com/dataset1/resourcelist.xml</loc>
|
|
1742
|
+
<rs:md capability="resourcelist"/>
|
|
1743
|
+
</url>
|
|
1744
|
+
<url>
|
|
1745
|
+
<loc>http://example.com/dataset1/resourcedump.xml</loc>
|
|
1746
|
+
<rs:md capability="resourcedump"/>
|
|
1747
|
+
</url>
|
|
1748
|
+
<url>
|
|
1749
|
+
<loc>http://example.com/dataset1/changelist.xml</loc>
|
|
1750
|
+
<rs:md capability="changelist"/>
|
|
1751
|
+
</url>
|
|
1752
|
+
<url>
|
|
1753
|
+
<loc>http://example.com/dataset1/changedump.xml</loc>
|
|
1754
|
+
<rs:md capability="changedump"/>
|
|
1755
|
+
</url>
|
|
1756
|
+
</urlset>
|
|
1757
|
+
</pre>
|
|
1758
|
+
</div>
|
|
1759
|
+
<p class="caption">Example 13: A Capability List</p>
|
|
1760
|
+
|
|
1761
|
+
<p>
|
|
1762
|
+
ResourceSync defines only a small number of capabilities, and enumerating those
|
|
1763
|
+
does not approach the limits of a single Capability List. Extensions or revisions
|
|
1764
|
+
of this specification may introduce the use of Capability List Indexes, but Sources
|
|
1765
|
+
should not generate such structures for the features introduced in this version
|
|
1766
|
+
of the ResourceSync specification.
|
|
1767
|
+
</p>
|
|
1768
|
+
|
|
1769
|
+
|
|
1770
|
+
<h2>10. <a name="DescResources">Describing Resources</a></h2>
|
|
1771
|
+
<p>
|
|
1772
|
+
A Source may publish a description of the resources it makes available
|
|
1773
|
+
for synchronization. This information enables a Destination to make an
|
|
1774
|
+
initial copy of some or all of those resources, or to update a local
|
|
1775
|
+
copy to remain synchronized with changes.
|
|
1776
|
+
</p>
|
|
1777
|
+
|
|
1778
|
+
<h3>10.1 <a name="ResourceList">Resource List</a></h3>
|
|
1779
|
+
<p>
|
|
1780
|
+
A <b>Resource List</b> is introduced to list and describe the resources
|
|
1781
|
+
that a Source makes available for synchronization.
|
|
1782
|
+
It presents a snapshot of a Source's resources at a particular point in time.
|
|
1783
|
+
</p>
|
|
1784
|
+
|
|
1785
|
+
<p>
|
|
1786
|
+
A Resource List is based on the <code><urlset></code> document format
|
|
1787
|
+
introduced by the Sitemap protocol. It has the <code><urlset></code>
|
|
1788
|
+
root element and the following structure:
|
|
1789
|
+
</p>
|
|
1790
|
+
<ul>
|
|
1791
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
1792
|
+
<code>capability</code> attribute that has a value of <code>resourcelist</code>. It must also have an
|
|
1793
|
+
<code>at</code> attribute that conveys the datetime at which the process of taking a snapshot of resources
|
|
1794
|
+
for their inclusion in the Resource List started, and it may have a <code>completed</code> attribute that conveys
|
|
1795
|
+
the datetime at which that process completed.</li>
|
|
1796
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
1797
|
+
<code>up</code>.</li>
|
|
1798
|
+
<li>In case a <a href="#ResourceListIndex">Resource List Index</a> exists,
|
|
1799
|
+
a recommended <code><rs:ln></code> child element of
|
|
1800
|
+
<code><urlset></code> points to it with the relation type <code>index</code>.</li>
|
|
1801
|
+
<li>One <code><url></code> child element of <code><urlset></code> should be included for each resource. This element does not have attributes, but uses
|
|
1802
|
+
child elements to convey information about the resource. The <code><url></code> element has the following child elements:
|
|
1803
|
+
<ul>
|
|
1804
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the resource.</li>
|
|
1805
|
+
<li>Optional <code><lastmod></code> and <code><changefreq></code> child
|
|
1806
|
+
element with semantics as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
1807
|
+
<li>An optional <code><rs:md></code> child element provides further metadata about
|
|
1808
|
+
the resource. It may have the attributes as described in
|
|
1809
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
1810
|
+
<li>Optional <code><rs:ln></code> child elements link to related resources as described in <a href="#DocumentFormats">Section 7</a>, and
|
|
1811
|
+
detailed in <a href="#LinkRelRes">Section 14</a>.</li>
|
|
1812
|
+
</ul>
|
|
1813
|
+
</li>
|
|
1814
|
+
</ul>
|
|
1815
|
+
<p>
|
|
1816
|
+
<a href="#ex_14">Example 14</a> shows a Resource List with two resources.
|
|
1817
|
+
The <code>at</code> attribute allows a Destination to determine that neither
|
|
1818
|
+
of the listed resources have undergone a change between their respective
|
|
1819
|
+
last modification datetimes, <code>2013-01-02T13:00:00Z</code> and
|
|
1820
|
+
<code>2013-01-02T14:00:00Z</code>, and the datetime that is the value of
|
|
1821
|
+
the <code>at</code> attribute, <code>2013-01-03T09:00:00Z</code>.
|
|
1822
|
+
</p>
|
|
1823
|
+
|
|
1824
|
+
<a name="ex_14"></a>
|
|
1825
|
+
<div class="exampleInner">
|
|
1826
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1827
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1828
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
1829
|
+
<rs:ln <span class="rs">rel="up"</span>
|
|
1830
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
1831
|
+
<rs:md <span class="rs">capability="resourcelist"
|
|
1832
|
+
at="2013-01-03T09:00:00Z"
|
|
1833
|
+
completed="2013-01-03T09:01:00Z"</span>/>
|
|
1834
|
+
<url>
|
|
1835
|
+
<span class="rs"><loc></span>http://example.com/res1<span class="rs"></loc></span>
|
|
1836
|
+
<span class="rs"><lastmod></span>2013-01-02T13:00:00Z<span class="rs"></lastmod></span>
|
|
1837
|
+
<span class="rs"><rs:md hash</span>="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
1838
|
+
<span class="rs">length</span>="8876"
|
|
1839
|
+
<span class="rs">type</span>="text/html"<span class="rs">/></span>
|
|
1840
|
+
</url>
|
|
1841
|
+
<url>
|
|
1842
|
+
<loc>http://example.com/res2</loc>
|
|
1843
|
+
<lastmod>2013-01-02T14:00:00Z</lastmod>
|
|
1844
|
+
<rs:md hash="md5:1e0d5cb8ef6ba40c99b14c0237be735e
|
|
1845
|
+
sha-256:854f61290e2e197a11bc91063afce22e43f8ccc655237050ace766adc68dc784"
|
|
1846
|
+
length="14599"
|
|
1847
|
+
type="application/pdf"/>
|
|
1848
|
+
</url>
|
|
1849
|
+
</urlset>
|
|
1850
|
+
</pre>
|
|
1851
|
+
</div>
|
|
1852
|
+
<p class="caption">Example 14: A Resource List</p>
|
|
1853
|
+
|
|
1854
|
+
<h3>10.2 <a name="ResourceListIndex"></a>Resource List Index</h3>
|
|
1855
|
+
|
|
1856
|
+
<p>
|
|
1857
|
+
The ResourceSync framework adopts the community-defined limits for publishing
|
|
1858
|
+
documents of the <code><urlset></code> format and
|
|
1859
|
+
introduces a <b>Resource List Index</b> for grouping multiple Resource Lists.
|
|
1860
|
+
The union of the Resource Lists referred to in the Resource List Index represents
|
|
1861
|
+
the entire set of resources that a Source makes available for synchronization.
|
|
1862
|
+
This set of resources, regardless of whether it is conveyed in a single Resource
|
|
1863
|
+
List or in multiple Resource Lists via
|
|
1864
|
+
a Resource List Index, represents the state of the Source's data at a point in time.
|
|
1865
|
+
</p>
|
|
1866
|
+
|
|
1867
|
+
<p>
|
|
1868
|
+
A Resource List Index is based on the <code><sitemapindex></code> document
|
|
1869
|
+
format introduced by the Sitemap protocol. It has the
|
|
1870
|
+
<code><sitemapindex></code> root element and the following structure:
|
|
1871
|
+
</p>
|
|
1872
|
+
<ul>
|
|
1873
|
+
<li>The mandatory <code><rs:md></code> child element of <code><sitemapindex></code> must have a
|
|
1874
|
+
<code>capability</code> attribute that has a value of <code>resourcelist</code>. It must also have an
|
|
1875
|
+
<code>at</code> attribute that conveys the datetime at which the process of taking a snapshot of resources
|
|
1876
|
+
for their inclusion in the Resource List Index started, and it may have a <code>completed</code> attribute that conveys
|
|
1877
|
+
the datetime at which that process completed.</li>
|
|
1878
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><sitemapindex></code> points to the Capability List with the relation type
|
|
1879
|
+
<code>up</code>.</li>
|
|
1880
|
+
<li>One <code><sitemap></code> child element of <code><sitemapindex></code>
|
|
1881
|
+
should be included for each Resource List. This element does not have attributes,
|
|
1882
|
+
but uses child elements to convey information about the Resource List. The
|
|
1883
|
+
<code><sitemap></code> element has the following child elements:
|
|
1884
|
+
<ul>
|
|
1885
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the Resource List.</li>
|
|
1886
|
+
<li>An optional <code><lastmod></code> child element with semantics as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
1887
|
+
<li>An optional <code><rs:md></code> child element with an <code>at</code> attribute and possibly a
|
|
1888
|
+
<code>completed</code> attribute to convey the datetime at which the process of taking a snapshot of resources
|
|
1889
|
+
for their inclusion in the Resource List respectively started and ended.</li>
|
|
1890
|
+
</ul>
|
|
1891
|
+
</li>
|
|
1892
|
+
</ul>
|
|
1893
|
+
<p>
|
|
1894
|
+
The Destination can determine whether it has reached a Resource List or
|
|
1895
|
+
a Resource List Index based on whether the root element is
|
|
1896
|
+
<code><urlset></code> or <code><sitemapindex></code>
|
|
1897
|
+
respectively. A Resource List Index that points to three Resource Lists
|
|
1898
|
+
is shown in <a href="#ex_15">Example 15</a>.
|
|
1899
|
+
</p>
|
|
1900
|
+
|
|
1901
|
+
<a name="ex_15"></a>
|
|
1902
|
+
<div class="exampleInner">
|
|
1903
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1904
|
+
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1905
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
1906
|
+
<rs:ln rel="up"
|
|
1907
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
1908
|
+
<rs:md <span class="rs">capability="resourcelist"</span>
|
|
1909
|
+
at="2013-01-03T09:00:00Z"
|
|
1910
|
+
completed="2013-01-03T09:10:00Z"/>
|
|
1911
|
+
<sitemap>
|
|
1912
|
+
<loc>http://example.com/resourcelist1.xml</loc>
|
|
1913
|
+
<span class="rs"><rs:md at="2013-01-03T09:00:00Z"/></span>
|
|
1914
|
+
</sitemap>
|
|
1915
|
+
<sitemap>
|
|
1916
|
+
<loc>http://example.com/resourcelist2.xml</loc>
|
|
1917
|
+
<span class="rs"><rs:md at="2013-01-03T09:03:00Z"/></span>
|
|
1918
|
+
</sitemap>
|
|
1919
|
+
<sitemap>
|
|
1920
|
+
<loc>http://example.com/resourcelist3.xml</loc>
|
|
1921
|
+
<span class="rs"><rs:md at="2013-01-03T09:07:00Z"/></span>
|
|
1922
|
+
</sitemap>
|
|
1923
|
+
</sitemapindex>
|
|
1924
|
+
</pre>
|
|
1925
|
+
</div>
|
|
1926
|
+
<p class="caption">Example 15: A Resource List Index</p>
|
|
1927
|
+
|
|
1928
|
+
<p>
|
|
1929
|
+
<a href="#ex_16">Example 16</a> shows the content of the Resource List identified by the URI
|
|
1930
|
+
<code>http://example.com/resourcelist1.xml</code>.
|
|
1931
|
+
Structurally, it is identical to the Resource List shown in <a href="#ex_14">Example 14</a>
|
|
1932
|
+
but it contains an additional
|
|
1933
|
+
<code><rs:ln></code> child element of <code><urlset></code>
|
|
1934
|
+
that provides a navigational link with the relation type <code>index</code> to the parent Resource List Index
|
|
1935
|
+
shown in <a href="#ex_15">Example 15</a>.
|
|
1936
|
+
This link is meant to ease navigation for Destinations and their adoption is therefore recommended.
|
|
1937
|
+
</p>
|
|
1938
|
+
<a name="ex_16"></a>
|
|
1939
|
+
<div class="exampleInner">
|
|
1940
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
1941
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
1942
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
1943
|
+
<rs:ln rel="up"
|
|
1944
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
1945
|
+
<rs:ln <span class="rs">rel="index"</span>
|
|
1946
|
+
href="http://example.com/dataset1/resourcelist-index.xml"/>
|
|
1947
|
+
<rs:md capability="resourcelist"
|
|
1948
|
+
at="2013-01-03T09:00:00Z"/>
|
|
1949
|
+
<url>
|
|
1950
|
+
<loc>http://example.com/res3</loc>
|
|
1951
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
1952
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c8753"
|
|
1953
|
+
length="4385"
|
|
1954
|
+
type="application/pdf"/>
|
|
1955
|
+
</url>
|
|
1956
|
+
<url>
|
|
1957
|
+
<loc>http://example.com/res4</loc>
|
|
1958
|
+
<lastmod>2013-01-02T14:00:00Z</lastmod>
|
|
1959
|
+
<rs:md hash="md5:4556abdf8ebdc9802ac0c6a7402c9881"
|
|
1960
|
+
length="883"
|
|
1961
|
+
type="image/png"/>
|
|
1962
|
+
</url>
|
|
1963
|
+
</urlset>
|
|
1964
|
+
</pre>
|
|
1965
|
+
</div>
|
|
1966
|
+
<p class="caption">Example 16: A Resource List with a navigational link to its parent Resource List Index</p>
|
|
1967
|
+
|
|
1968
|
+
|
|
1969
|
+
<h2>11. <a name="PackResources">Packaging Resources</a></h2>
|
|
1970
|
+
<p>
|
|
1971
|
+
In order to provide Destinations with an efficient way to copy a Source's
|
|
1972
|
+
data using a small number of HTTP requests, a Source may provide packaged
|
|
1973
|
+
bitstreams for its resources.
|
|
1974
|
+
</p>
|
|
1975
|
+
|
|
1976
|
+
<h3>11.1 <a name="ResourceDump">Resource Dump</a></h3>
|
|
1977
|
+
<p>
|
|
1978
|
+
A Source may publish a <strong>Resource Dump</strong>, which provides links
|
|
1979
|
+
to packages of the resources' bitstreams. The Resource Dump represents the
|
|
1980
|
+
Source's state at a point in time. It may be used to transfer resources from
|
|
1981
|
+
the Source in bulk, rather than the Destination having to make many separate
|
|
1982
|
+
requests.
|
|
1983
|
+
</p>
|
|
1984
|
+
<p>
|
|
1985
|
+
The ResourceSync framework specifies the use of the <a href="#ref-zip">ZIP file format</a> as
|
|
1986
|
+
the packaging format. Communities may define their own packaging format.
|
|
1987
|
+
A Resource Dump should only point to packages of the same format.
|
|
1988
|
+
</p>
|
|
1989
|
+
<p>
|
|
1990
|
+
A Resource Dump is based on the <code><urlset></code> document format
|
|
1991
|
+
introduced by the Sitemap protocol. It has the <code><urlset></code> root
|
|
1992
|
+
element and the following structure:
|
|
1993
|
+
</p>
|
|
1994
|
+
<ul>
|
|
1995
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
1996
|
+
<code>capability</code> attribute that has a value of <code>resourcedump</code>. It must also have an
|
|
1997
|
+
<code>at</code> attribute that conveys the datetime at which the process of taking a snapshot of resources
|
|
1998
|
+
for their inclusion in the Resource Dump started, and it may have a <code>completed</code> attribute that conveys
|
|
1999
|
+
the datetime at which that process completed.</li>
|
|
2000
|
+
<li> A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
2001
|
+
<code>up</code>.</li>
|
|
2002
|
+
<li>In case a <a href="#ResourceDumpIndex">Resource Dump Index</a> exists,
|
|
2003
|
+
a recommended <code><rs:ln></code> child element of
|
|
2004
|
+
<code><urlset></code> points to it with the relation type <code>index</code>.</li>
|
|
2005
|
+
<li>One <code><url></code> child element of <code><urlset></code>
|
|
2006
|
+
should be included for each bitstream package. This element does not have attributes,
|
|
2007
|
+
but uses child elements to convey information about the package. The
|
|
2008
|
+
<code><url></code> element has the following child elements:
|
|
2009
|
+
<ul>
|
|
2010
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the package.</li>
|
|
2011
|
+
<li>An optional <code><lastmod></code> child element with semantics as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2012
|
+
<li>A recommended <code><rs:md></code> child element to convey the Media Type and
|
|
2013
|
+
the length of the package using the <code>type</code> and <code>length</code>
|
|
2014
|
+
attribute, respectively. It may also have an <code>at</code> attribute and possibly
|
|
2015
|
+
a <code>completed</code> attribute to convey the datetime at which the process
|
|
2016
|
+
of taking a snapshot of resources
|
|
2017
|
+
for their inclusion in the package respectively started and ended.
|
|
2018
|
+
The child element may further have attributes such as
|
|
2019
|
+
<code>hash</code>, as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2020
|
+
<li>An optional <code><rs:ln></code> child element with the relation type <code>contents</code> that points to the Resource Dump Manifest
|
|
2021
|
+
associated with the bitstream package.</li>
|
|
2022
|
+
</ul>
|
|
2023
|
+
</li>
|
|
2024
|
+
</ul>
|
|
2025
|
+
<p>
|
|
2026
|
+
<a href="#ex_17">Example 17</a> shows a Resource Dump that points to three ZIP files.
|
|
2027
|
+
Included in each <code><url></code> element is a pointer to the
|
|
2028
|
+
<a href="#ResourceDumpManifest">Resource Dump Manifest</a> associated with
|
|
2029
|
+
the package. While this pointer is optional and intended for the Destination's
|
|
2030
|
+
convenience, if provided, the Source needs to ensure that the referred Manifest
|
|
2031
|
+
corresponds with the Manifest included in the bitstream package.
|
|
2032
|
+
</p>
|
|
2033
|
+
|
|
2034
|
+
<a name="ex_17"></a>
|
|
2035
|
+
<div class="exampleInner">
|
|
2036
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2037
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2038
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2039
|
+
<rs:ln rel="up"
|
|
2040
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2041
|
+
<rs:md <span class="rs">capability="resourcedump"</span>
|
|
2042
|
+
at="2013-01-03T09:00:00Z"
|
|
2043
|
+
completed="2013-01-03T09:04:00Z"/>
|
|
2044
|
+
<url>
|
|
2045
|
+
<loc>http://example.com/resourcedump-part1.zip</loc>
|
|
2046
|
+
<rs:md <span class="rs">type="application/zip"
|
|
2047
|
+
length="4765"
|
|
2048
|
+
at="2013-01-03T09:00:00Z"
|
|
2049
|
+
completed="2013-01-03T09:02:00Z"</span>/>
|
|
2050
|
+
<rs:ln <span class="rs">rel="contents"</span>
|
|
2051
|
+
href="http://example.com/resourcedump_manifest-part1.xml"
|
|
2052
|
+
type="application/xml"/>
|
|
2053
|
+
</url>
|
|
2054
|
+
<url>
|
|
2055
|
+
<loc>http://example.com/resourcedump-part2.zip</loc>
|
|
2056
|
+
<rs:md type="application/zip"
|
|
2057
|
+
length="9875"
|
|
2058
|
+
at="2013-01-03T09:01:00Z"
|
|
2059
|
+
completed="2013-01-03T09:03:00Z"/>
|
|
2060
|
+
<rs:ln rel="contents"
|
|
2061
|
+
href="http://example.com/resourcedump_manifest-part2.xml"
|
|
2062
|
+
type="application/xml"/>
|
|
2063
|
+
</url>
|
|
2064
|
+
<url>
|
|
2065
|
+
<loc>http://example.com/resourcedump-part3.zip</loc>
|
|
2066
|
+
<rs:md type="application/zip"
|
|
2067
|
+
length="2298"
|
|
2068
|
+
at="2013-01-03T09:03:00Z"
|
|
2069
|
+
completed="2013-01-03T09:04:00Z"/>
|
|
2070
|
+
<rs:ln rel="contents"
|
|
2071
|
+
href="http://example.com/resourcedump_manifest-part3.xml"
|
|
2072
|
+
type="application/xml"/>
|
|
2073
|
+
</url>
|
|
2074
|
+
</urlset>
|
|
2075
|
+
</pre>
|
|
2076
|
+
</div>
|
|
2077
|
+
<p class="caption">Example 17: A Resource Dump</p>
|
|
2078
|
+
|
|
2079
|
+
<p>
|
|
2080
|
+
If a Source needs to or chooses to publish multiple Resource Dumps, it must
|
|
2081
|
+
group them using a <a name="ResourceDumpIndex">Resource Dump Index</a>,
|
|
2082
|
+
in a manner that is similar to what was described in
|
|
2083
|
+
<a href="#ResourceListIndex">Section 11.2</a>.
|
|
2084
|
+
</p>
|
|
2085
|
+
|
|
2086
|
+
<h3>11.2 <a name="ResourceDumpManifest">Resource Dump Manifest</a></h3>
|
|
2087
|
+
<p>
|
|
2088
|
+
Each ZIP package referred to from a Resource Dump must contain a <b>Resource Dump Manifest</b>
|
|
2089
|
+
file that describes the package's constituent bitstreams. The file must be named <code>manifest.xml</code>
|
|
2090
|
+
and must be located at the top level of the ZIP package.
|
|
2091
|
+
</p>
|
|
2092
|
+
|
|
2093
|
+
<p>
|
|
2094
|
+
The Resource Dump Manifest is based on the <code><urlset></code> format.
|
|
2095
|
+
It has the <code><urlset></code> root element and the following structure:
|
|
2096
|
+
</p>
|
|
2097
|
+
<ul>
|
|
2098
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
2099
|
+
<code>capability</code> attribute with a value of <code>resourcedump-manifest</code>. It must also have an
|
|
2100
|
+
<code>at</code> attribute that conveys the datetime at which the process of taking a snapshot of resources
|
|
2101
|
+
for their inclusion in the ZIP package started, and it may have a <code>completed</code> attribute that conveys
|
|
2102
|
+
the datetime at which that process completed.</li>
|
|
2103
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
2104
|
+
<code>up</code>.</li>
|
|
2105
|
+
<li>One <code><url></code> child element of <code><urlset></code> per bitstream. This element does not have attributes, but uses
|
|
2106
|
+
child elements to convey information about the bitstream. The <code><url></code> element has the following child elements:
|
|
2107
|
+
<ul>
|
|
2108
|
+
<li>A mandatory <code><loc></code> child element provides the URI that the Source associates with the bitstream.</li>
|
|
2109
|
+
<li>Optional <code><lastmod></code> and <code><changefreq></code> child elements with semantics as described in <a href="#DocumentFormats">Section 7</a>.
|
|
2110
|
+
</li>
|
|
2111
|
+
<li>A mandatory <code><rs:md></code> child element must have a <code>path</code>
|
|
2112
|
+
attribute to convey the location of the bitstream within the package. The value
|
|
2113
|
+
of the attribute is relative to root of the package and it is expressed with a
|
|
2114
|
+
leading slash (/). The use of the <code>type</code> attribute in the
|
|
2115
|
+
<code><rs:md></code> element is recommended to help Destinations determine
|
|
2116
|
+
the Media Type of the bitstream. The <code><rs:md></code> element may further
|
|
2117
|
+
have the attributes <code>hash</code> and <code>length</code>, as described in
|
|
2118
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
2119
|
+
<li>Optional <code><rs:ln></code> child elements link to related resources
|
|
2120
|
+
as described in <a href="#DocumentFormats">Section 7</a>, and detailed in
|
|
2121
|
+
<a href="#LinkRelRes">Section 14</a>.</li>
|
|
2122
|
+
</ul>
|
|
2123
|
+
</li>
|
|
2124
|
+
</ul>
|
|
2125
|
+
|
|
2126
|
+
<p>
|
|
2127
|
+
<a href="#ex_18">Example 18</a> shows a Resource Dump Manifest for a ZIP file that contains two bitstreams.
|
|
2128
|
+
</p>
|
|
2129
|
+
|
|
2130
|
+
<a name="ex_18"></a>
|
|
2131
|
+
<div class="exampleInner">
|
|
2132
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2133
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2134
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2135
|
+
<rs:ln rel="up"
|
|
2136
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2137
|
+
<rs:md <span class="rs">capability="resourcedump-manifest"</span>
|
|
2138
|
+
at="2013-01-03T09:00:00Z"
|
|
2139
|
+
completed="2013-01-03T09:02:00Z"/>
|
|
2140
|
+
<url>
|
|
2141
|
+
<loc>http://example.com/res1</loc>
|
|
2142
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
2143
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
2144
|
+
length="8876"
|
|
2145
|
+
type="text/html"
|
|
2146
|
+
<span class="rs">path="/resources/res1"</span>/>
|
|
2147
|
+
</url>
|
|
2148
|
+
<url>
|
|
2149
|
+
<loc>http://example.com/res2</loc>
|
|
2150
|
+
<lastmod>2013-01-02T14:00:00Z</lastmod>
|
|
2151
|
+
<rs:md hash="md5:1e0d5cb8ef6ba40c99b14c0237be735e
|
|
2152
|
+
sha-256:854f61290e2e197a11bc91063afce22e43f8ccc655237050ace766adc68dc784"
|
|
2153
|
+
length="14599"
|
|
2154
|
+
type="application/pdf"
|
|
2155
|
+
<span class="rs">path="/resources/res2"</span>/>
|
|
2156
|
+
</url>
|
|
2157
|
+
</urlset>
|
|
2158
|
+
</pre>
|
|
2159
|
+
</div>
|
|
2160
|
+
<p class="caption">Example 18: A Resource Dump Manifest</p>
|
|
2161
|
+
|
|
2162
|
+
|
|
2163
|
+
<h2>12. <a name="DesChanges">Describing Changes</a></h2>
|
|
2164
|
+
<p>
|
|
2165
|
+
A Source may publish a record of the changes to its resources.
|
|
2166
|
+
This enables Destinations to efficiently learn about those changes and
|
|
2167
|
+
hence to synchronize incrementally.
|
|
2168
|
+
</p>
|
|
2169
|
+
|
|
2170
|
+
<h3>12.1 <a name="ChangeList">Change List</a></h3>
|
|
2171
|
+
<p>
|
|
2172
|
+
A <b>Change List</b> is a document that contains a description of changes to a Source's resources.
|
|
2173
|
+
It is up to the Source to determine the publication frequency of Change Lists, as well as the temporal interval they cover.
|
|
2174
|
+
For example, a Source may choose to publish a fixed number of changes per Change List, or all the changes in a period of fixed length,
|
|
2175
|
+
such as an hour, a day, or a week. All entries in a Change List must be provided in forward chronological order:
|
|
2176
|
+
the least recently changed resource must be listed at the beginning of the
|
|
2177
|
+
Change List, while the most recently changed resource must be listed at the end of the document.
|
|
2178
|
+
If a resource underwent multiple changes in the period covered by a Change List, then it will be listed multiple times, once per change.
|
|
2179
|
+
</p>
|
|
2180
|
+
|
|
2181
|
+
<p>
|
|
2182
|
+
A Change List is based on the <code><urlset></code> document format introduced by the Sitemap protocol.
|
|
2183
|
+
It has the <code><urlset></code> root element and the following structure:
|
|
2184
|
+
</p>
|
|
2185
|
+
|
|
2186
|
+
<ul>
|
|
2187
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
2188
|
+
<code>capability</code> attribute that has a value of <code>changelist</code>. It also has the mandatory
|
|
2189
|
+
<code>from</code> and the optional <code>until</code> attributes to convey the temporal interval
|
|
2190
|
+
covered by the Change List. Details about the semantics of these attributes are provided below.</li>
|
|
2191
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
2192
|
+
<code>up</code>.</li>
|
|
2193
|
+
<li>In case a <a href="#ChangeListIndex">Change List Index</a> exists,
|
|
2194
|
+
a recommended <code><rs:ln></code> child element of
|
|
2195
|
+
<code><urlset></code> points to it with the relation type
|
|
2196
|
+
<code>index</code>.</li>
|
|
2197
|
+
<li>One <code><url></code> child element of <code><urlset></code>
|
|
2198
|
+
should be included for each resource change. This element does not have attributes,
|
|
2199
|
+
but uses child elements to convey information about the changed resource.
|
|
2200
|
+
The <code><url></code> element has the following child elements:
|
|
2201
|
+
<ul>
|
|
2202
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the changed resource.</li>
|
|
2203
|
+
<li>A mandatory <code><lastmod></code> and an optional
|
|
2204
|
+
<code><changefreq></code> child element with semantics as described in
|
|
2205
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
2206
|
+
<li>A mandatory <code><rs:md></code> child element must have the attribute <code>change</code> to convey the nature of the change.
|
|
2207
|
+
Its value is <code>created</code>, <code>updated</code>, or <code>deleted</code>.
|
|
2208
|
+
It may further have attributes <code>hash</code>, <code>length</code>, and
|
|
2209
|
+
<code>type</code>, as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2210
|
+
<li>Optional <code><rs:ln></code> child elements link to related
|
|
2211
|
+
resources as described in <a href="#DocumentFormats">Section 7</a>
|
|
2212
|
+
and detailed in <a href="#LinkRelRes">Section 14</a>.</li>
|
|
2213
|
+
</ul>
|
|
2214
|
+
</li>
|
|
2215
|
+
</ul>
|
|
2216
|
+
|
|
2217
|
+
<p>The temporal interval covered by a Change List is conveyed by means of the <code>from</code> and <code>until</code> attributes of the
|
|
2218
|
+
<code><rs:md></code> child element of the <code><urlset></code> root element.
|
|
2219
|
+
The <code>from</code> attribute indicates that the Change List includes all changes that
|
|
2220
|
+
occurred to the set of resources at the Source since the datetime expressed as the value
|
|
2221
|
+
of the attribute. If it exists, the <code>until</code> attribute indicates that the Change List
|
|
2222
|
+
includes all changes that occurred to the set of resources at the Source up until the
|
|
2223
|
+
datetime expressed as the value of the attribute. Its use is optional for Change Lists:</p>
|
|
2224
|
+
<ul>
|
|
2225
|
+
<li>When a document carries the <code>until</code> attribute, this indicates that the document
|
|
2226
|
+
will not be updated anymore; the Change List is closed.
|
|
2227
|
+
When a Destination has finished processing a closed Change List, it should consult the enclosing
|
|
2228
|
+
Change List Index (following the link with the <code>index</code> relation type), if applicable,
|
|
2229
|
+
or the Capability List (following the link with the <code>up</code> relation type)
|
|
2230
|
+
to determine the URI of the Change List that reports the changes that occurred after the datetime expressed as the closed Change List's <code>until</code> value.
|
|
2231
|
+
</li>
|
|
2232
|
+
<li>When a document does not carry the <code>until</code> attribute, this
|
|
2233
|
+
indicates that the document will be updated with further changes; the Change
|
|
2234
|
+
List remains open. A Destination should continue to poll an open Change List
|
|
2235
|
+
to learn about further changes. It does not need to consult the enclosing
|
|
2236
|
+
Change List Index, if applicable, nor the Capability List.
|
|
2237
|
+
</li>
|
|
2238
|
+
</ul>
|
|
2239
|
+
|
|
2240
|
+
<p>
|
|
2241
|
+
The <code>from</code> and <code>until</code> attributes help a Destination to
|
|
2242
|
+
determine whether it has or has not fully processed a Change List. The forward
|
|
2243
|
+
chronological order of changes in a Change List, the datetime of a resource
|
|
2244
|
+
change, and the URI of a changed resource help the Destination to determine
|
|
2245
|
+
the first unprocessed change in a not fully processed Change List.
|
|
2246
|
+
The Destination should start processing there; it can retrieve a representation
|
|
2247
|
+
of a changed resource by dereferencing its URI provided in the <code><loc></code>
|
|
2248
|
+
child element of the <code><url></code> element that conveys the change.
|
|
2249
|
+
In order for the determination of the first unprocessed change to be accurate,
|
|
2250
|
+
the combination of the URI of a changed resource and the datetime of its change
|
|
2251
|
+
should be unique. Hence, a Source should provide change datetime values at a
|
|
2252
|
+
sufficiently fine granularity.
|
|
2253
|
+
</p>
|
|
2254
|
+
|
|
2255
|
+
<p>
|
|
2256
|
+
<a href="#ex_19">Example 19</a> shows a Change List that indicates that four
|
|
2257
|
+
resource changes occurred since 2013-01-03T00:00:00Z: one creation, two
|
|
2258
|
+
updates, and one deletion. One resource underwent two of these changes and
|
|
2259
|
+
hence is listed twice. The Change List has no <code>until</code> attribute,
|
|
2260
|
+
which indicates that it will report further changes; a Destination should
|
|
2261
|
+
keep polling this Change List.
|
|
2262
|
+
</p>
|
|
2263
|
+
|
|
2264
|
+
<a name="ex_19"></a>
|
|
2265
|
+
<div class="exampleInner">
|
|
2266
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2267
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2268
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2269
|
+
<rs:ln rel="up"
|
|
2270
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2271
|
+
<rs:md <span class="rs">capability="changelist"
|
|
2272
|
+
from="2013-01-03T00:00:00Z"</span>/>
|
|
2273
|
+
<url>
|
|
2274
|
+
<loc>http://example.com/res1.html</loc>
|
|
2275
|
+
<lastmod><span class="rs">2013-01-03T11:00:00Z</span></lastmod>
|
|
2276
|
+
<rs:md <span class="rs">change="created"</span>/>
|
|
2277
|
+
</url>
|
|
2278
|
+
<url>
|
|
2279
|
+
<loc>http://example.com/res2.pdf</loc>
|
|
2280
|
+
<lastmod><span class="rs">2013-01-03T13:00:00Z</span></lastmod>
|
|
2281
|
+
<rs:md <span class="rs">change="updated"</span>/>
|
|
2282
|
+
</url>
|
|
2283
|
+
<url>
|
|
2284
|
+
<loc>http://example.com/res3.tiff</loc>
|
|
2285
|
+
<lastmod><span class="rs">2013-01-03T18:00:00Z</span></lastmod>
|
|
2286
|
+
<rs:md <span class="rs">change="deleted"</span>/>
|
|
2287
|
+
</url>
|
|
2288
|
+
<url>
|
|
2289
|
+
<loc><span class="rs">http://example.com/res2.pdf</span></loc>
|
|
2290
|
+
<lastmod><span class="rs">2013-01-03T21:00:00Z</span></lastmod>
|
|
2291
|
+
<rs:md <span class="rs">change="updated"</span>/>
|
|
2292
|
+
</url>
|
|
2293
|
+
</urlset>
|
|
2294
|
+
</pre>
|
|
2295
|
+
</div>
|
|
2296
|
+
<p class="caption">Example 19: An open Change List describing four resource changes</p>
|
|
2297
|
+
|
|
2298
|
+
<h3>12.2 <a name="ChangeListIndex">Change List Index</a></h3>
|
|
2299
|
+
|
|
2300
|
+
<p>
|
|
2301
|
+
If a Source needs to publish multiple Change Lists, it must group them in a Change List Index.
|
|
2302
|
+
A Change List Index must enumerate Change Lists in forward chronological order.
|
|
2303
|
+
</p>
|
|
2304
|
+
|
|
2305
|
+
<p>
|
|
2306
|
+
A Change List Index is based on the <code><sitemapindex></code> document format introduced by the Sitemap protocol.
|
|
2307
|
+
It has the <code><sitemapindex></code> root element and the following structure:
|
|
2308
|
+
</p>
|
|
2309
|
+
<ul>
|
|
2310
|
+
<li>The mandatory <code><rs:md></code> child element of <code><sitemapindex></code> must have a
|
|
2311
|
+
<code>capability</code> attribute that has a value of <code>changelist</code>. It also has the mandatory
|
|
2312
|
+
<code>from</code> and the optional <code>until</code> attributes to convey the temporal interval
|
|
2313
|
+
covered by the Change List Index. The semantics of these attributes are as explained in detail for
|
|
2314
|
+
<a href="#ChangeList">Change Lists</a>.</li>
|
|
2315
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><sitemapindex></code>
|
|
2316
|
+
points to the Capability List with the relation type <code>up</code>.</li>
|
|
2317
|
+
<li>One <code><sitemap></code> child element of <code><sitemapindex></code>
|
|
2318
|
+
should be included for each Change List. This element does not have attributes, but
|
|
2319
|
+
uses child elements to convey information about the Change List. The
|
|
2320
|
+
<code><sitemap></code> element has the following child elements:
|
|
2321
|
+
<ul>
|
|
2322
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the Change List.</li>
|
|
2323
|
+
<li>An optional <code><lastmod></code> child element with semantics as described in
|
|
2324
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
2325
|
+
<li>A recommended <code><rs:md></code> child element with the <code>from</code> and possibly <code>until</code>
|
|
2326
|
+
attributes to convey the temporal interval covered by the Change List. The use of the <code>until</code> is as follows:
|
|
2327
|
+
<ul>
|
|
2328
|
+
<li>If the Change List is closed the use of <code><until></code> is required.</li>
|
|
2329
|
+
<li>If the Change List is open <code><until></code> must not be provided.</li>
|
|
2330
|
+
</ul>
|
|
2331
|
+
</li>
|
|
2332
|
+
</ul>
|
|
2333
|
+
</li>
|
|
2334
|
+
</ul>
|
|
2335
|
+
|
|
2336
|
+
<p>
|
|
2337
|
+
The Destination should determine whether it has reached a Change List or a
|
|
2338
|
+
Change List Index based on whether the root element is
|
|
2339
|
+
<code><urlset></code> or <code><sitemapindex></code> respectively.
|
|
2340
|
+
</p>
|
|
2341
|
+
<p>
|
|
2342
|
+
A Change List Index that points to three Change Lists is shown in
|
|
2343
|
+
<a href="#ex_20">Example 20</a>. Two of those Change Lists are closed, as
|
|
2344
|
+
indicated by the provision of <code><lastmod></code>, and one is open,
|
|
2345
|
+
as indicated by its absence. The closed Change List
|
|
2346
|
+
<code>http://example.com/20130102-changelist.xml</code> is shown in
|
|
2347
|
+
<a href="#ex_21">Example 21</a>. Note that the value for <code><lastmod></code>
|
|
2348
|
+
for this Change List in the Change List Index is the same as the value of
|
|
2349
|
+
the <code>until</code> attribute in the Change List: <code>2013-01-02T23:59:59Z</code>.
|
|
2350
|
+
The open Change List could be the one shown in
|
|
2351
|
+
<a href="#ex_19">Example 19</a>, in which case that list would have an additional link
|
|
2352
|
+
with an <code>index</code> relation type pointing to the Change List Index.
|
|
2353
|
+
</p>
|
|
2354
|
+
|
|
2355
|
+
<a name="ex_20"></a>
|
|
2356
|
+
<div class="exampleInner">
|
|
2357
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2358
|
+
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2359
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2360
|
+
<rs:ln rel="up"
|
|
2361
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2362
|
+
<rs:md <span class="rs">capability="changelist"
|
|
2363
|
+
from="2013-01-01T00:00:00Z"</span>/>
|
|
2364
|
+
<sitemap>
|
|
2365
|
+
<loc>http://example.com/20130101-changelist.xml</loc>
|
|
2366
|
+
<rs:md <span class="rs">from="2013-01-01T00:00:00Z"
|
|
2367
|
+
until="2013-01-02T00:00:00Z"</span>/>
|
|
2368
|
+
</sitemap>
|
|
2369
|
+
<sitemap>
|
|
2370
|
+
<loc>http://example.com/20130102-changelist.xml</loc>
|
|
2371
|
+
<rs:md from="2013-01-02T00:00:00Z"
|
|
2372
|
+
until="2013-01-03T00:00:00Z"/>
|
|
2373
|
+
</sitemap>
|
|
2374
|
+
<sitemap>
|
|
2375
|
+
<loc>http://example.com/20130103-changelist.xml</loc>
|
|
2376
|
+
<rs:md from="2013-01-03T00:00:00Z"/>
|
|
2377
|
+
</sitemap>
|
|
2378
|
+
</sitemapindex>
|
|
2379
|
+
</pre>
|
|
2380
|
+
</div>
|
|
2381
|
+
<p class="caption">Example 20: A Change List Index</p>
|
|
2382
|
+
|
|
2383
|
+
<a name="ex_21"></a>
|
|
2384
|
+
<div class="exampleInner">
|
|
2385
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2386
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2387
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2388
|
+
<rs:ln rel="up"
|
|
2389
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2390
|
+
<rs:ln <span class="rs">rel="index"</span>
|
|
2391
|
+
href="http://example.com/dataset1/changelist.xml"/>
|
|
2392
|
+
<rs:md <span class="rs">capability="changelist"
|
|
2393
|
+
from="2013-01-02T00:00:00Z"
|
|
2394
|
+
until="2013-01-03T00:00:00Z"</span>/>
|
|
2395
|
+
<url>
|
|
2396
|
+
<loc>http://example.com/res7.html</loc>
|
|
2397
|
+
<lastmod>2013-01-02T12:00:00Z</lastmod>
|
|
2398
|
+
<rs:md change="created"/>
|
|
2399
|
+
</url>
|
|
2400
|
+
<url>
|
|
2401
|
+
<loc>http://example.com/res9.pdf</loc>
|
|
2402
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
2403
|
+
<rs:md change="updated"/>
|
|
2404
|
+
</url>
|
|
2405
|
+
<url>
|
|
2406
|
+
<loc>http://example.com/res5.tiff</loc>
|
|
2407
|
+
<lastmod>2013-01-02T19:00:00Z</lastmod>
|
|
2408
|
+
<rs:md change="deleted"/>
|
|
2409
|
+
</url>
|
|
2410
|
+
<url>
|
|
2411
|
+
<loc>http://example.com/res7.html</loc>
|
|
2412
|
+
<lastmod>2013-01-02T20:00:00Z</lastmod>
|
|
2413
|
+
<rs:md change="updated"/>
|
|
2414
|
+
</url>
|
|
2415
|
+
</urlset>
|
|
2416
|
+
</pre>
|
|
2417
|
+
</div>
|
|
2418
|
+
<p class="caption">Example 21: A closed Change List pointing back to its Index</p>
|
|
2419
|
+
|
|
2420
|
+
|
|
2421
|
+
<h2>13. <a name="PackChanges">Packaging Changes</a></h2>
|
|
2422
|
+
<p>
|
|
2423
|
+
In order to reduce the number of requests required to obtain resource changes,
|
|
2424
|
+
a Source may provide packaged bitstreams for changed resources.
|
|
2425
|
+
</p>
|
|
2426
|
+
|
|
2427
|
+
<h3>13.1 <a name="ChangeDump">Change Dump</a></h3>
|
|
2428
|
+
<p>
|
|
2429
|
+
To make content changes available for download, a Source may publish
|
|
2430
|
+
<b>Change Dumps</b>. A Change Dump is a document that points to packages
|
|
2431
|
+
containing bitstreams for the Source's changed resources.
|
|
2432
|
+
The ResourceSync framework specifies the use of the <a href="#ref-zip">ZIP file format</a> as
|
|
2433
|
+
the packaging format. Communities may define their own packaging format.
|
|
2434
|
+
A Change Dump should only point to packages of the same format.
|
|
2435
|
+
</p>
|
|
2436
|
+
<p>
|
|
2437
|
+
It is up to the Source to determine the publication frequency of these packages,
|
|
2438
|
+
as well as the temporal interval they cover.
|
|
2439
|
+
For example, a Source may choose to publish a fixed number of changes per package, or all the
|
|
2440
|
+
changes in a period of fixed length, such as an hour, a day, or a week.
|
|
2441
|
+
If a resource underwent multiple changes in the period covered by a package,
|
|
2442
|
+
then the package will contain multiple bitstreams for the resource, one per change.
|
|
2443
|
+
As new packages are published, new entries are added to the Change Dump that points at them.
|
|
2444
|
+
All entries in a Change Dump should be provided in forward chronological
|
|
2445
|
+
order: the least recently published package listed at the beginning of the
|
|
2446
|
+
Change Dump, the most recent package listed at the end of the document.
|
|
2447
|
+
</p>
|
|
2448
|
+
|
|
2449
|
+
<p>
|
|
2450
|
+
A Change Dump is based on the <code><urlset></code> document format
|
|
2451
|
+
introduced by the Sitemap protocol. It has the <code><urlset></code>
|
|
2452
|
+
root element and the following structure:
|
|
2453
|
+
</p>
|
|
2454
|
+
<ul>
|
|
2455
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
2456
|
+
<code>capability</code> attribute that has a value of <code>changedump</code>. It also has the
|
|
2457
|
+
mandatory <code>from</code> and the optional <code>until</code> attributes to convey the temporal interval
|
|
2458
|
+
covered by the Change Dump. The semantics of these attributes are as explained in detail for
|
|
2459
|
+
<a href="#ChangeList">Change Lists</a>.</li>
|
|
2460
|
+
<li> A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
2461
|
+
<code>up</code>.</li>
|
|
2462
|
+
<li>In case a <a href="#ChangeDumpIndex">Change Dump Index</a> exists,
|
|
2463
|
+
a recommended <code><rs:ln></code> child element of
|
|
2464
|
+
<code><urlset></code> points to it with the relation type
|
|
2465
|
+
<code>index</code>.</li>
|
|
2466
|
+
<li>One <code><url></code> child element of <code><urlset></code>
|
|
2467
|
+
should be included for each bitstream package. This element does not have
|
|
2468
|
+
attributes, but uses child elements to convey information about the package.
|
|
2469
|
+
The <code><url></code> element has the following child elements:
|
|
2470
|
+
<ul>
|
|
2471
|
+
<li>A mandatory <code><loc></code> child element provides the URI of the package.</li>
|
|
2472
|
+
<li>An optional <code><lastmod></code> child element with semantics as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2473
|
+
<li>A recommended <code><rs:md></code> child element to convey the Media Type
|
|
2474
|
+
and the length of the package using the <code>type</code> and <code>length</code>
|
|
2475
|
+
attribute, respectively. It may also have the <code>from</code> and <code>until</code>
|
|
2476
|
+
attributes to convey the temporal interval covered by the package. The child element
|
|
2477
|
+
may further have attributes such as <code>hash</code>, as described in
|
|
2478
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
2479
|
+
<li>An optional <code><rs:ln></code> child element with the relation type <code>contents</code> that points to
|
|
2480
|
+
a copy of the Change Dump Manifest associated with each package.</li>
|
|
2481
|
+
</ul>
|
|
2482
|
+
</li>
|
|
2483
|
+
</ul>
|
|
2484
|
+
|
|
2485
|
+
<p>
|
|
2486
|
+
<a href="#ex_22">Example 22</a> shows a Change Dump with pointers to three
|
|
2487
|
+
bitstream packages associated with changed resources. The absence of the
|
|
2488
|
+
<code>until</code> attribute indicates that further packages will be added.
|
|
2489
|
+
The example also includes within each <code><url></code> element a pointer to a copy of
|
|
2490
|
+
the <a href="#ChangeDumpManifest">Change Dump Manifest</a> associated with the package.
|
|
2491
|
+
This pointer is optional and intended to allow a Destination
|
|
2492
|
+
to determine whether the package should be downloaded.
|
|
2493
|
+
If such pointers are provided, the Source must ensure that the Manifest referred to
|
|
2494
|
+
matches the Manifest included in the bitstream package.
|
|
2495
|
+
</p>
|
|
2496
|
+
|
|
2497
|
+
<a name="ex_22"></a>
|
|
2498
|
+
<div class="exampleInner">
|
|
2499
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2500
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2501
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2502
|
+
<rs:ln rel="up"
|
|
2503
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2504
|
+
<rs:md <span class="rs">capability="changedump"</span>
|
|
2505
|
+
from="2013-01-01T00:00:00Z"/>
|
|
2506
|
+
<url>
|
|
2507
|
+
<loc>http://example.com/20130101-changedump.zip</loc>
|
|
2508
|
+
<lastmod>2013-01-01T23:59:59Z</lastmod>
|
|
2509
|
+
<rs:md <span class="rs">type="application/zip"
|
|
2510
|
+
length="3109"
|
|
2511
|
+
from="2013-01-01T00:00:00Z"
|
|
2512
|
+
until="2013-01-02T00:00:00Z"</span>/>
|
|
2513
|
+
<rs:ln <span class="rs">rel="contents"</span>
|
|
2514
|
+
href="http://example.com/20130101-changedump-manifest.xml"
|
|
2515
|
+
type="application/xml"/>
|
|
2516
|
+
</url>
|
|
2517
|
+
<url>
|
|
2518
|
+
<loc>http://example.com/20130102-changedump.zip</loc>
|
|
2519
|
+
<lastmod>2013-01-02T23:59:59Z</lastmod>
|
|
2520
|
+
<rs:md type="application/zip"
|
|
2521
|
+
length="6629"
|
|
2522
|
+
from="2013-01-02T00:00:00Z"
|
|
2523
|
+
until="2013-01-03T00:00:00Z"/>
|
|
2524
|
+
<rs:ln rel="contents"
|
|
2525
|
+
href="http://example.com/20130102-changedump-manifest.xml"
|
|
2526
|
+
type="application/xml"/>
|
|
2527
|
+
</url>
|
|
2528
|
+
<url>
|
|
2529
|
+
<loc>http://example.com/20130103-changedump.zip</loc>
|
|
2530
|
+
<lastmod>2013-01-03T23:59:59Z</lastmod>
|
|
2531
|
+
<rs:md type="application/zip"
|
|
2532
|
+
length="8124"
|
|
2533
|
+
from="2013-01-03T00:00:00Z"
|
|
2534
|
+
until="2013-01-04T00:00:00Z"/>
|
|
2535
|
+
<rs:ln rel="contents"
|
|
2536
|
+
href="http://example.com/20130103-changedump-manifest.xml"
|
|
2537
|
+
type="application/xml"/>
|
|
2538
|
+
</url>
|
|
2539
|
+
</urlset>
|
|
2540
|
+
</pre>
|
|
2541
|
+
</div>
|
|
2542
|
+
<p class="caption">Example 22: A Change Dump</p>
|
|
2543
|
+
<p>
|
|
2544
|
+
If a Source needs to publish multiple Change Dumps, it must group them in
|
|
2545
|
+
a <a name="ChangeDumpIndex">Change Dump Index</a>, in a manner similar to
|
|
2546
|
+
what was described in <a href="#ChangeListIndex">Section 12.2</a>.
|
|
2547
|
+
</p>
|
|
2548
|
+
|
|
2549
|
+
<h3>13.2 <a name="ChangeDumpManifest">Change Dump Manifest</a></h3>
|
|
2550
|
+
<p>
|
|
2551
|
+
Each ZIP package referred to from a Change Dump must contain a
|
|
2552
|
+
<b>Change Dump Manifest</b> file that describes the constituent bitstreams of the package.
|
|
2553
|
+
The file must be named <code>manifest.xml</code>
|
|
2554
|
+
and must be located at the top level of the ZIP package.
|
|
2555
|
+
All entries in a Change Dump Manifest must be provided in forward chronological order:
|
|
2556
|
+
the bitstream associated with the least
|
|
2557
|
+
recent resource change is listed first, and the bitstream associated with the most recent change
|
|
2558
|
+
is listed last.
|
|
2559
|
+
</p>
|
|
2560
|
+
|
|
2561
|
+
<p>
|
|
2562
|
+
The Change Dump Manifest is based on the <code><urlset></code> format.
|
|
2563
|
+
It has the <code><urlset></code> root element and the following structure:
|
|
2564
|
+
</p>
|
|
2565
|
+
<ul>
|
|
2566
|
+
<li>The mandatory <code><rs:md></code> child element of <code><urlset></code> must have a
|
|
2567
|
+
<code>capability</code> attribute that has a value of <code>changedump-manifest</code>.
|
|
2568
|
+
It also has the mandatory
|
|
2569
|
+
<code>from</code> and the optional <code>until</code> attributes to convey the temporal interval
|
|
2570
|
+
covered by the ZIP package in which the Change Dump Manifest is contained:
|
|
2571
|
+
bitstream for all resource changes that occurred during the specified
|
|
2572
|
+
interval must be included in the ZIP package and the Change Dump Manifest must refer to each.</li>
|
|
2573
|
+
<li>A mandatory <code><rs:ln></code> child element of <code><urlset></code> points to the Capability List with the relation type
|
|
2574
|
+
<code>up</code>.</li>
|
|
2575
|
+
<li>One <code><url></code> child element of <code><urlset></code>
|
|
2576
|
+
should be included for each resource change, and hence for each bitstream.
|
|
2577
|
+
This element does not have attributes, but uses child elements to convey
|
|
2578
|
+
information about the resource change and its associated bitstream.
|
|
2579
|
+
The <code><url></code> element has the following child elements:
|
|
2580
|
+
<ul>
|
|
2581
|
+
<li>A mandatory <code><loc></code> child element provides the URI
|
|
2582
|
+
which the Source associates with the bitstream.</li>
|
|
2583
|
+
<li>A mandatory <code><lastmod></code> and an optional <code><changefreq></code> child element
|
|
2584
|
+
with semantics as described in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2585
|
+
<li>A mandatory <code><rs:md></code> child element must have a <code>change</code>
|
|
2586
|
+
attribute to convey the type of change the resource underwent. The <code>change</code>
|
|
2587
|
+
attribute value may be <code>created</code>, <code>updated</code>, or <code>deleted</code>.
|
|
2588
|
+
Except in the case of <code>change="deleted"</code>, the element must also have a
|
|
2589
|
+
<code>path</code> attribute to convey the location of the bitstream within the ZIP
|
|
2590
|
+
package. The path is relative to root of the package and it is expressed with a
|
|
2591
|
+
leading slash (/). The use of the <code>type</code> attribute in the
|
|
2592
|
+
<code><rs:md></code> element is strongly recommended to help Destinations
|
|
2593
|
+
determine the Media Type of the bitstream. The <code><rs:md></code> element may
|
|
2594
|
+
further have the attributes <code>hash</code> and <code>length</code>, as described in
|
|
2595
|
+
<a href="#DocumentFormats">Section 7</a>.</li>
|
|
2596
|
+
<li>Optional <code><rs:ln></code> child elements link to related resources
|
|
2597
|
+
as described in <a href="#DocumentFormats">Section 7</a> and detailed in <a href="#LinkRelRes">Section 14</a>.</li>
|
|
2598
|
+
</ul>
|
|
2599
|
+
</li>
|
|
2600
|
+
</ul>
|
|
2601
|
+
<p>
|
|
2602
|
+
<a href="#ex_23">Example 23</a> shows the Change Dump Manifest associated with the
|
|
2603
|
+
second entry in the Resource Dump from <a href="#ex_22">Example 22</a>. The Manifest
|
|
2604
|
+
must be named <code>manifest.xml</code> at the top level of the ZIP package. A copy
|
|
2605
|
+
of the Manifest may also be provided at a location indicated by an
|
|
2606
|
+
optional <code><rs:ln></code> element with the relation type
|
|
2607
|
+
<code>contents</code> in the Change Dump,
|
|
2608
|
+
<code>http://example.com/20130102-changedump-manifest.xml</code> in
|
|
2609
|
+
<a href="#ex_22">Example 22</a>. The Manifest covers the same
|
|
2610
|
+
changes as conveyed in the closed Change List of <a href="#ex_21">Example 21</a>.
|
|
2611
|
+
The resource <code>http://example.com/res7.html</code> is listed twice, once
|
|
2612
|
+
because it was created, and once because it was updated. Both entries have
|
|
2613
|
+
the same URI. The ZIP package in which this Manifest is contained has two
|
|
2614
|
+
bitstreams for this resource, available at different paths in the package.
|
|
2615
|
+
</p>
|
|
2616
|
+
|
|
2617
|
+
<a name="ex_23"></a>
|
|
2618
|
+
<div class="exampleInner">
|
|
2619
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2620
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2621
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2622
|
+
<rs:ln rel="up"
|
|
2623
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2624
|
+
<rs:md <span class="rs">capability="changedump-manifest"
|
|
2625
|
+
from="2013-01-02T00:00:00Z"
|
|
2626
|
+
until="2013-01-03T00:00:00Z"</span>/>
|
|
2627
|
+
<url>
|
|
2628
|
+
<loc>http://example.com/res7.html</loc>
|
|
2629
|
+
<lastmod>2013-01-02T12:00:00Z</lastmod>
|
|
2630
|
+
<rs:md change="created"
|
|
2631
|
+
hash="md5:1c1b0e264fa9b7e1e9aa6f9db8d6362b"
|
|
2632
|
+
length="4339"
|
|
2633
|
+
type="text/html"
|
|
2634
|
+
<span class="rs">path="/changes/res7.html"</span>/>
|
|
2635
|
+
</url>
|
|
2636
|
+
<url>
|
|
2637
|
+
<loc>http://example.com/res9.pdf</loc>
|
|
2638
|
+
<lastmod>2013-01-02T13:00:00Z</lastmod>
|
|
2639
|
+
<rs:md change="updated"
|
|
2640
|
+
hash="md5:f906610c3d4aa745cb2b986f25b37c5a"
|
|
2641
|
+
length="38297"
|
|
2642
|
+
type="application/pdf"
|
|
2643
|
+
<span class="rs">path="/changes/res9.pdf"</span>/>
|
|
2644
|
+
</url>
|
|
2645
|
+
<url>
|
|
2646
|
+
<loc>http://example.com/res5.tiff</loc>
|
|
2647
|
+
<lastmod>2013-01-02T19:00:00Z</lastmod>
|
|
2648
|
+
<rs:md change="deleted"/>
|
|
2649
|
+
</url>
|
|
2650
|
+
<url>
|
|
2651
|
+
<loc>http://example.com/res7.html</loc>
|
|
2652
|
+
<lastmod>2013-01-02T20:00:00Z</lastmod>
|
|
2653
|
+
<rs:md change="updated"
|
|
2654
|
+
hash="md5:0988647082c8bc51778894a48ec3b576"
|
|
2655
|
+
length="5426"
|
|
2656
|
+
type="text/html"
|
|
2657
|
+
<span class="rs">path="/changes/res7-v2.html"</span>/>
|
|
2658
|
+
</url>
|
|
2659
|
+
</urlset>
|
|
2660
|
+
</pre>
|
|
2661
|
+
</div>
|
|
2662
|
+
<p class="caption">Example 23: A Change Dump Manifest</p>
|
|
2663
|
+
|
|
2664
|
+
|
|
2665
|
+
<h2>14. <a name="LinkRelRes">Linking to Related Resources</a></h2>
|
|
2666
|
+
|
|
2667
|
+
<h3>14.1 <a name="LinkRelRevOverview">Overview</a></h3>
|
|
2668
|
+
<p>
|
|
2669
|
+
In order to facilitate alternative approaches to obtain content for a
|
|
2670
|
+
resource that is subject to synchronization or to provide additional
|
|
2671
|
+
information about it, a Source may provide links from that resource to
|
|
2672
|
+
related resources. Such links may occur in Resource Lists, Resource Dump
|
|
2673
|
+
Manifests, Change Lists, and Change Dump Manifests. The following cases
|
|
2674
|
+
are considered and detailed (in examples of Change Lists) in the
|
|
2675
|
+
remainder of this section:
|
|
2676
|
+
</p>
|
|
2677
|
+
<ul>
|
|
2678
|
+
<li>The Source makes the resource content available at a mirror location.</li>
|
|
2679
|
+
<li>The Source provides alternate representations for the resource.</li>
|
|
2680
|
+
<li>The Source details the difference between the current and the previous version
|
|
2681
|
+
of the resource.</li>
|
|
2682
|
+
<li>The Source makes a resource as well as metadata about the resource available
|
|
2683
|
+
for synchronization.</li>
|
|
2684
|
+
<li>The Source provides access to prior versions of the resource.</li>
|
|
2685
|
+
<li>The Source provides collection membership information about the resource.</li>
|
|
2686
|
+
<li>A Destination republishes a resource obtained from a Source, makes that
|
|
2687
|
+
republished resource available for synchronization (i.e. acts as a Source itself),
|
|
2688
|
+
and links to the original resource that it republished.</li>
|
|
2689
|
+
</ul>
|
|
2690
|
+
|
|
2691
|
+
<p>
|
|
2692
|
+
As always, the <code><loc></code> child element of <code><url></code>
|
|
2693
|
+
conveys the URI of the resource that is subject to synchronization. The related
|
|
2694
|
+
resource is provided by means of the <code><rs:ln></code> child element
|
|
2695
|
+
of <code><url></code>. The possible attributes for
|
|
2696
|
+
<code><rs:ln></code> as well as the link relation types used to address
|
|
2697
|
+
the aforementioned use cases are detailed in <a href="#DocumentFormats">Section 7</a>.
|
|
2698
|
+
Links to meet needs other than the ones listed may be provided, and appropriate
|
|
2699
|
+
relation types may be selected from the
|
|
2700
|
+
<a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA Link Relation Type Registry</a>
|
|
2701
|
+
or expressed as URIs as specified in <a href="#ref-rfc5988">RFC 5988, Sec. 4.2</a>.
|
|
2702
|
+
</p>
|
|
2703
|
+
|
|
2704
|
+
<p>
|
|
2705
|
+
In case a Destination is not able to adequately interpret the information conveyed in
|
|
2706
|
+
an <code><rs:ln></code> element, it should refrain from accessing the related
|
|
2707
|
+
resource and rather use the URI provided in <code><loc></code> to retrieve
|
|
2708
|
+
the resource.
|
|
2709
|
+
</p>
|
|
2710
|
+
|
|
2711
|
+
<h3>14.2 <a name="MirCon">Mirrored Content</a></h3>
|
|
2712
|
+
<p>
|
|
2713
|
+
In order to reduce the load on its primary access mechanism, a Source may convey
|
|
2714
|
+
one or mirror locations for a resource. An <code><rs:ln></code> element
|
|
2715
|
+
is introduced to express each mirror location for the resource. This element
|
|
2716
|
+
has the following attributes:</p>
|
|
2717
|
+
<ul>
|
|
2718
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>duplicate</code>.</li>
|
|
2719
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI of the mirrored resource.</li>
|
|
2720
|
+
<li>An optional <code>pri</code> attribute to express a prioritization among multiple mirror locations, each expressed by means of an individual
|
|
2721
|
+
<code><rs:ln></code> element. The use of <code>pri</code> is detailed in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2722
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
2723
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2724
|
+
</ul>
|
|
2725
|
+
|
|
2726
|
+
<p>
|
|
2727
|
+
<a href="#ex_24">Example 24</a> shows how a Source conveys information about
|
|
2728
|
+
prioritized mirror locations for a resource. Since the three locations conveyed
|
|
2729
|
+
by <code><rs:ln></code> elements point to duplicates of the resource specified in
|
|
2730
|
+
<code><loc></code>, the values for each of the attributes of
|
|
2731
|
+
<code><rs:md></code> are expected to be identical for the resource and its
|
|
2732
|
+
mirrors. Hence, they should be omitted from the <code><rs:ln></code> elements.
|
|
2733
|
+
The last <code><rs:ln></code> element points to a mirror location where the
|
|
2734
|
+
resource is accessible via a protocol other than HTTP as can be seen from the URI
|
|
2735
|
+
scheme. Even though the resources are duplicates, their last modified datetimes may vary.
|
|
2736
|
+
</p>
|
|
2737
|
+
|
|
2738
|
+
<a name="ex_24"></a>
|
|
2739
|
+
<div class="exampleInner">
|
|
2740
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2741
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2742
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2743
|
+
<rs:ln rel="up"
|
|
2744
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2745
|
+
<rs:md capability="changelist"
|
|
2746
|
+
from="2013-01-03T00:00:00Z"/>
|
|
2747
|
+
<url>
|
|
2748
|
+
<loc>http://example.com/res1</loc>
|
|
2749
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
2750
|
+
<rs:md change="updated"
|
|
2751
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
2752
|
+
length="8876"
|
|
2753
|
+
type="text/html"/>
|
|
2754
|
+
<rs:ln <span class="rs">rel="duplicate"</span>
|
|
2755
|
+
<span class="rs">pri="1"</span>
|
|
2756
|
+
href="http://mirror1.example.com/res1"
|
|
2757
|
+
modified="2013-01-03T18:00:00Z"/>
|
|
2758
|
+
<rs:ln <span class="rs">rel="duplicate"</span>
|
|
2759
|
+
<span class="rs">pri="2"</span>
|
|
2760
|
+
href="http://mirror2.example.com/res1"
|
|
2761
|
+
modified="2013-01-03T18:00:00Z"/>
|
|
2762
|
+
<rs:ln <span class="rs">rel="duplicate"</span>
|
|
2763
|
+
<span class="rs">pri="3"</span>
|
|
2764
|
+
href="gsiftp://gridftp.example.com/res1"
|
|
2765
|
+
modified="2013-01-03T18:00:00Z"/>
|
|
2766
|
+
</url>
|
|
2767
|
+
</urlset>
|
|
2768
|
+
</pre>
|
|
2769
|
+
</div>
|
|
2770
|
+
<p class="caption">Example 24: Mirrored content</p>
|
|
2771
|
+
|
|
2772
|
+
|
|
2773
|
+
<h3>14.3 <a name="AltRep">Alternate Representations</a></h3>
|
|
2774
|
+
<p>
|
|
2775
|
+
A resource may have multiple representations available from different URIs.
|
|
2776
|
+
A resource may, for example, be identified by a generic URI such as
|
|
2777
|
+
<code>http://example.com/res1</code>. After performing content negotiation
|
|
2778
|
+
with the server, a client may, for example, obtain the resource's HTML
|
|
2779
|
+
representation available from the specific URI
|
|
2780
|
+
<code>http://example.com/res1.html</code>. Another client may ask for and
|
|
2781
|
+
retrieve the PDF representation of the
|
|
2782
|
+
resource from the specific URI <code>http://example.com/res1.pdf</code>.
|
|
2783
|
+
Which representation a client obtains, can, amongst others, depend on its
|
|
2784
|
+
preferences in terms of Media Type and language, its geographical location,
|
|
2785
|
+
and its device type.
|
|
2786
|
+
</p>
|
|
2787
|
+
<p>
|
|
2788
|
+
A Source may express that a resource is subject to synchronization by conveying its
|
|
2789
|
+
generic URI in <code><loc></code>. In this case, per alternate representation
|
|
2790
|
+
that the Source wants to advertise, an <code><rs:ln></code> element is
|
|
2791
|
+
introduced. This element has the following attributes:
|
|
2792
|
+
</p>
|
|
2793
|
+
<ul>
|
|
2794
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>alternate</code>.</li>
|
|
2795
|
+
<li>A mandatory <code>href</code> attribute that conveys the specific URI of the alternate
|
|
2796
|
+
representation of the resource.</li>
|
|
2797
|
+
<li>A recommended <code>type</code> attribute that conveys the Media Type of the
|
|
2798
|
+
alternate representation.</li>
|
|
2799
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
2800
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2801
|
+
</ul>
|
|
2802
|
+
|
|
2803
|
+
<p>
|
|
2804
|
+
Cases exist in which there is no generic URI for a resource, only specific URIs.
|
|
2805
|
+
This may occur, for example, when a resource has different representations
|
|
2806
|
+
available for different devices.
|
|
2807
|
+
In this case the URI in <code><loc></code> will be a specific URI, and
|
|
2808
|
+
<code><rs:ln></code> elements with an <code>alternate</code> relation
|
|
2809
|
+
type are still used to refer to alternate representations available from other
|
|
2810
|
+
specific URIs.
|
|
2811
|
+
</p>
|
|
2812
|
+
<p>
|
|
2813
|
+
<a href="#ex_25">Example 25</a> shows how to promote a generic URI in <code><loc></code>
|
|
2814
|
+
while also pointing to alternate representations available from specific URIs,
|
|
2815
|
+
for example, through content negotiation.
|
|
2816
|
+
</p>
|
|
2817
|
+
|
|
2818
|
+
<a name="ex_25"></a>
|
|
2819
|
+
<div class="exampleInner">
|
|
2820
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2821
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2822
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2823
|
+
<rs:ln rel="up"
|
|
2824
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2825
|
+
<rs:md capability="changelist"
|
|
2826
|
+
from="2013-01-03T11:00:00Z"/>
|
|
2827
|
+
<url>
|
|
2828
|
+
<loc>http://example.com/res1</loc>
|
|
2829
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
2830
|
+
<rs:md change="updated"/>
|
|
2831
|
+
<rs:ln <span class="rs">rel="alternate"</span>
|
|
2832
|
+
href="http://example.com/res1.html"
|
|
2833
|
+
modified="2013-01-03T18:00:00Z"
|
|
2834
|
+
<span class="rs">type="text/html"</span>/>
|
|
2835
|
+
<rs:ln rel="alternate"
|
|
2836
|
+
href="http://example.com/res1.pdf"
|
|
2837
|
+
modified="2013-01-03T18:00:00Z"
|
|
2838
|
+
<span class="rs">type="application/pdf"</span>/>
|
|
2839
|
+
</url>
|
|
2840
|
+
</urlset>
|
|
2841
|
+
</pre>
|
|
2842
|
+
</div>
|
|
2843
|
+
<p class="caption">Example 25: Generic URI and alternates with specific URIs</p>
|
|
2844
|
+
|
|
2845
|
+
<p>
|
|
2846
|
+
In cases where a particular representation is considered the subject of synchronization,
|
|
2847
|
+
its specific URI is provided in <code><loc></code>. The associated
|
|
2848
|
+
generic URI, if one exists, may be provided using an <code><rs:ln></code>
|
|
2849
|
+
element. This element has the following attributes:
|
|
2850
|
+
</p>
|
|
2851
|
+
<ul>
|
|
2852
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>canonical</code>.</li>
|
|
2853
|
+
<li>A mandatory <code>href</code> attribute that conveys the generic URI associated with the
|
|
2854
|
+
specific URI provided in <code><loc></code>.</li>
|
|
2855
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
2856
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2857
|
+
</ul>
|
|
2858
|
+
|
|
2859
|
+
<p>
|
|
2860
|
+
This approach might be most appropriate for Resource Dump Manifests and Change Dump Manifests
|
|
2861
|
+
that describe bitstreams contained in a ZIP file.
|
|
2862
|
+
</p>
|
|
2863
|
+
<p>
|
|
2864
|
+
<a href="#ex_26">Example 26</a> shows a Source promoting a specific URI
|
|
2865
|
+
in <code><loc></code> while also pointing to the
|
|
2866
|
+
resource's generic URI by means of an <code><rs:ln></code> element.
|
|
2867
|
+
Metadata pertaining to the representation available from that specific URI is
|
|
2868
|
+
conveyed by means of attributes of the <code><rs:md></code> element.
|
|
2869
|
+
</p>
|
|
2870
|
+
|
|
2871
|
+
<a name="ex_26"></a>
|
|
2872
|
+
<div class="exampleInner">
|
|
2873
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2874
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2875
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2876
|
+
<rs:ln rel="up"
|
|
2877
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2878
|
+
<rs:md capability="changelist"
|
|
2879
|
+
from="2013-01-03T00:00:00Z"/>
|
|
2880
|
+
<url>
|
|
2881
|
+
<loc>http://example.com/res1.html</loc>
|
|
2882
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
2883
|
+
<rs:md change="updated"
|
|
2884
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
2885
|
+
length="8876"/>
|
|
2886
|
+
<rs:ln <span class="rs">rel="canonical"</span>
|
|
2887
|
+
href="http://example.com/res1"
|
|
2888
|
+
modified="2013-01-03T18:00:00Z"/>
|
|
2889
|
+
</url>
|
|
2890
|
+
</urlset>
|
|
2891
|
+
</pre>
|
|
2892
|
+
</div>
|
|
2893
|
+
<p class="caption">Example 26: Specific URI and alternate with generic URI</p>
|
|
2894
|
+
|
|
2895
|
+
<h3>14.4 <a name="PatchCon">Patching Content</a></h3>
|
|
2896
|
+
<p>
|
|
2897
|
+
In order to increase the efficiency of updating a resource, a Source may make a
|
|
2898
|
+
description available of the changes that the resource underwent, in addition
|
|
2899
|
+
to the entire changed resource. Especially when frequent minor changes and/or
|
|
2900
|
+
changes to large resources are concerned, such an approach may be attractive.
|
|
2901
|
+
It will, however, require an unambiguous way to describe the changes in such
|
|
2902
|
+
a way that a Destination can construct the most recent version of the resource
|
|
2903
|
+
by appropriately patching the previous version with the description of the changes.
|
|
2904
|
+
</p>
|
|
2905
|
+
|
|
2906
|
+
<p>
|
|
2907
|
+
A Source may express that it makes a description of resource changes available
|
|
2908
|
+
by providing the URI of the resource in <code><loc></code>, as usual, and by
|
|
2909
|
+
introducing an <code><rs:ln></code> element with the following attributes:
|
|
2910
|
+
</p>
|
|
2911
|
+
<ul>
|
|
2912
|
+
<li>A mandatory <code>rel</code> attribute with a value of
|
|
2913
|
+
<code>http://www.openarchives.org/rs/terms/patch</code>.</li>
|
|
2914
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI of the description
|
|
2915
|
+
of the resource changes.</li>
|
|
2916
|
+
<li>A mandatory <code>type</code> attribute that conveys the Media Type of the
|
|
2917
|
+
change description. That Media Type must be such that it allows the unambiguous
|
|
2918
|
+
application of the described changes to the previous version of the resource to
|
|
2919
|
+
construct the current one.</li>
|
|
2920
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element
|
|
2921
|
+
of <code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
2922
|
+
</ul>
|
|
2923
|
+
|
|
2924
|
+
<p><a href="#ex_27">Example 27</a> shows a Source that expresses changes that a
|
|
2925
|
+
JSON resource underwent expressed using the <code>application/json-patch</code>
|
|
2926
|
+
Media Type introduced in <a href="#ref-json-patch">JSON Patch</a>. It also shows
|
|
2927
|
+
the Source conveying changes to a large TIFF file using an experimental Media
|
|
2928
|
+
Type that may, for example, be described in a community specification.
|
|
2929
|
+
A Destination that does not understand the Media Type should ignore the
|
|
2930
|
+
description of changes and use the URI in <code><loc></code>
|
|
2931
|
+
to obtain the most recent version of the resource. Another example of a
|
|
2932
|
+
well-specified Media Type for expressing changes to XML document is
|
|
2933
|
+
<code>application/patch-ops-error+xml</code>, as specified in
|
|
2934
|
+
<a href="#ref-rfc5261">RFC 5261</a>.
|
|
2935
|
+
</p>
|
|
2936
|
+
<p>
|
|
2937
|
+
Expressing resource changes in this manner is only applicable to Change Lists
|
|
2938
|
+
(as in <a href="#ex_27">Example 27</a>) and Change Dumps.
|
|
2939
|
+
When doing so for a Change Dump, the entry in the Change Dump Manifest must
|
|
2940
|
+
have the <code>path</code> attribute for the <code><rs:ln></code>
|
|
2941
|
+
element that points to the change description that is included in the content package.
|
|
2942
|
+
</p>
|
|
2943
|
+
<a name="ex_27"></a>
|
|
2944
|
+
<div class="exampleInner">
|
|
2945
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
2946
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
2947
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
2948
|
+
<rs:ln rel="up"
|
|
2949
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
2950
|
+
<rs:md capability="changelist"
|
|
2951
|
+
from="2013-01-03T00:00:00Z"/>
|
|
2952
|
+
<url>
|
|
2953
|
+
<loc>http://example.com/res4</loc>
|
|
2954
|
+
<lastmod>2013-01-03T17:00:00Z</lastmod>
|
|
2955
|
+
<rs:md change="updated"
|
|
2956
|
+
hash="sha-256:f4OxZX_x_DFGFDgghgdfb6rtSx-iosjf6735432nklj"
|
|
2957
|
+
length="56778"
|
|
2958
|
+
<span class="rs">type="application/json"</span>/>
|
|
2959
|
+
<rs:ln <span class="rs">rel="http://www.openarchives.org/rs/terms/patch"</span>
|
|
2960
|
+
href="http://example.com/res4-json-patch"
|
|
2961
|
+
modified="2013-01-03T17:00:00Z"
|
|
2962
|
+
hash="sha-256:y66dER_t_HWEIKpesdkeb7rtSc-ippjf9823742opld"
|
|
2963
|
+
length="73"
|
|
2964
|
+
<span class="rs">type="application/json-patch"</span>/>
|
|
2965
|
+
</url>
|
|
2966
|
+
<url>
|
|
2967
|
+
<loc>http://example.com/res5-full.tiff</loc>
|
|
2968
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
2969
|
+
<rs:md change="updated"
|
|
2970
|
+
hash="sha-256:f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk"
|
|
2971
|
+
length="9788456778"
|
|
2972
|
+
<span class="rs">type="image/tiff"</span>/>
|
|
2973
|
+
<rs:ln <span class="rs">rel="http://www.openarchives.org/rs/terms/patch"</span>
|
|
2974
|
+
href="http://example.com/res5-diff"
|
|
2975
|
+
modified="2013-01-03T18:00:00Z"
|
|
2976
|
+
hash="sha-256:h986gT_t_87HTkjHYE76G558hY-jdfgy76t55sadJUYT"
|
|
2977
|
+
length="4533"
|
|
2978
|
+
<span class="rs">type="application/x-tiff-diff"</span>/>
|
|
2979
|
+
</url>
|
|
2980
|
+
</urlset>
|
|
2981
|
+
</pre>
|
|
2982
|
+
</div>
|
|
2983
|
+
<p class="caption">Example 27: A Change List with links to document that detail how to patch resources</p>
|
|
2984
|
+
|
|
2985
|
+
<h3>14.5 <a name="ResMDLinking">Resources and Metadata about Resources</a></h3>
|
|
2986
|
+
<p>
|
|
2987
|
+
Cases exist where both resources and metadata about those resources must be synchronized.
|
|
2988
|
+
From the ResourceSync perspective, both the resource and the metadata about it are regarded as resources
|
|
2989
|
+
with distinct URIs that are subject to synchronization. As usual, each gets its distinct
|
|
2990
|
+
<code><url></code> block and each URI is conveyed in a <code><loc></code> child element of the
|
|
2991
|
+
respective block. If required, the inter-relationship between both resources is expressed by means of
|
|
2992
|
+
an <code><rs:ln></code> element with appropriate relation types added to each block.
|
|
2993
|
+
The <code><rs:ln></code>
|
|
2994
|
+
element has the following attributes:
|
|
2995
|
+
</p>
|
|
2996
|
+
<ul>
|
|
2997
|
+
<li>A mandatory <code>rel</code> attribute. When pointing from a resource to metadata that describes it,
|
|
2998
|
+
its value is <code>describedby</code>; when pointing from metadata to the resource described by the metadata,
|
|
2999
|
+
its value is
|
|
3000
|
+
<code>describes</code>.</li>
|
|
3001
|
+
<li>A mandatory <code>href</code> attribute. When pointing from a resource to metadata that describes it,
|
|
3002
|
+
its value is the URI of the metadata resource; when pointing from metadata to the resource described by it,
|
|
3003
|
+
the value is the URI of the described resource.</li>
|
|
3004
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
3005
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
3006
|
+
</ul>
|
|
3007
|
+
|
|
3008
|
+
<p>
|
|
3009
|
+
<a href="#ex_28">Example 28</a> shows how a Source may express this inter-relationship
|
|
3010
|
+
between the two resources. Note that a Destination can use the metadata that
|
|
3011
|
+
describes a resource as a filtering mechanism to only synchronize with those
|
|
3012
|
+
resources that meet its metadata-based selection criteria. Note also in the
|
|
3013
|
+
<code><url></code> element that conveys the metadata record update,
|
|
3014
|
+
the use of the link with a <code>profile</code> relation type
|
|
3015
|
+
[<a href="#ref-rfc6906">RFC 6906</a>] to express the kind of metadata that
|
|
3016
|
+
is used to describe the resource, in this case, expressed by means of its
|
|
3017
|
+
XML Namespace. The link should provide a URI that supports the Destination
|
|
3018
|
+
in interpreting the metadata information. For example, it could refer to a
|
|
3019
|
+
namespace, an XML schema, or a description of MARC.
|
|
3020
|
+
</p>
|
|
3021
|
+
|
|
3022
|
+
<a name="ex_28"></a>
|
|
3023
|
+
<div class="exampleInner">
|
|
3024
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3025
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3026
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3027
|
+
<rs:ln rel="up"
|
|
3028
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
3029
|
+
<rs:md capability="changelist"
|
|
3030
|
+
from="2013-01-03T00:00:00Z"/>
|
|
3031
|
+
<url>
|
|
3032
|
+
<loc>http://example.com/res2.pdf</loc>
|
|
3033
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
3034
|
+
<rs:md change="updated"
|
|
3035
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3036
|
+
length="8876"
|
|
3037
|
+
type="application/pdf"/>
|
|
3038
|
+
<rs:ln <span class="rs">rel="describedby"</span>
|
|
3039
|
+
href="http://example.com/res2_dublin-core_metadata.xml"
|
|
3040
|
+
modified="2013-01-01T12:00:00Z"
|
|
3041
|
+
type="application/xml"/>
|
|
3042
|
+
</url>
|
|
3043
|
+
<url>
|
|
3044
|
+
<loc>http://example.com/res2_dublin-core_metadata.xml</loc>
|
|
3045
|
+
<lastmod>2013-01-03T19:00:00Z</lastmod>
|
|
3046
|
+
<rs:md change="updated"
|
|
3047
|
+
type="application/xml"/>
|
|
3048
|
+
<rs:ln <span class="rs">rel="describes"</span>
|
|
3049
|
+
href="http://example.com/res2.pdf"
|
|
3050
|
+
modified="2013-01-03T18:00:00Z"
|
|
3051
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3052
|
+
length="8876"
|
|
3053
|
+
type="application/pdf"/>
|
|
3054
|
+
<rs:ln <span class="rs">rel="profile"</span>
|
|
3055
|
+
href="http://purl.org/dc/elements/1.1/"/>
|
|
3056
|
+
</url>
|
|
3057
|
+
</urlset>
|
|
3058
|
+
</pre>
|
|
3059
|
+
</div>
|
|
3060
|
+
<p class="caption">Example 28: Linking between a resource and metadata about a resource in a Change List</p>
|
|
3061
|
+
|
|
3062
|
+
<h3>14.6 <a name="ResVers">Prior Versions of Resources</a></h3>
|
|
3063
|
+
<p>
|
|
3064
|
+
A Source may provide access to prior versions of a resource to allow Destinations to obtain a
|
|
3065
|
+
historical perspective, rather than just remaining synchronized with the most recent version.
|
|
3066
|
+
The approach to do so leverages a common resource versioning paradigm that consists of:
|
|
3067
|
+
</p>
|
|
3068
|
+
<ul>
|
|
3069
|
+
<li>The existence of a time-generic URI from which, at any moment in time, the current representation of the
|
|
3070
|
+
resource is available.</li>
|
|
3071
|
+
<li>The existence of a time-specific URI for each resource version, from which a specific temporal version of
|
|
3072
|
+
the resource is available.</li>
|
|
3073
|
+
</ul>
|
|
3074
|
+
<p>
|
|
3075
|
+
When communicating about the resource, its time-generic URI is provided in <code><loc></code> and
|
|
3076
|
+
<code><lastmod></code> must be used to provide the resource's last modification time.
|
|
3077
|
+
</p>
|
|
3078
|
+
<p>
|
|
3079
|
+
A first approach consists of conveying the time-specific URI of the resource that
|
|
3080
|
+
corresponds with the time of last modification, as given in the <code><lastmod></code> element.
|
|
3081
|
+
This is achieved by introducing a single <code><rs:ln></code> element with
|
|
3082
|
+
the following attributes:
|
|
3083
|
+
</p>
|
|
3084
|
+
<ul>
|
|
3085
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>memento</code>.</li>
|
|
3086
|
+
<li>A mandatory <code>href</code> attribute that conveys the time-specific URI of
|
|
3087
|
+
the resource that corresponds with the time of last modification.
|
|
3088
|
+
This URI allows a Destination to obtain that specific version during a catch-up
|
|
3089
|
+
operation, for example, because it had been offline, even if the resource has
|
|
3090
|
+
meanwhile changed again.</li>
|
|
3091
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
3092
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
3093
|
+
</ul>
|
|
3094
|
+
|
|
3095
|
+
<p>
|
|
3096
|
+
A second approach consists of pointing to a TimeGate associated with the
|
|
3097
|
+
time-generic resource. A TimeGate supports negotiation in the datetime dimension,
|
|
3098
|
+
as introduced in the Memento protocol [<a href="#ref-memento">Memento Internet Draft</a>],
|
|
3099
|
+
to obtain a version of the resource as it existed at a specified moment in time.
|
|
3100
|
+
This allows the Destination to obtain the version that existed at the time of last
|
|
3101
|
+
modification by using the <code><lastmod></code> value in the datetime
|
|
3102
|
+
negotiation process, but also allows the Destination to obtain other versions by
|
|
3103
|
+
using different datetime values. A pointer to a TimeGate is introduced by using an
|
|
3104
|
+
<code><rs:ln></code> element with the following attributes:
|
|
3105
|
+
</p>
|
|
3106
|
+
<ul>
|
|
3107
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>timegate</code>.</li>
|
|
3108
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI of TimeGate associated with the
|
|
3109
|
+
time-generic resource.</li>
|
|
3110
|
+
<li>The other attributes described for the <code><rs:ln></code> child element of
|
|
3111
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>
|
|
3112
|
+
should not be used as they are meaningless for TimeGates.</li>
|
|
3113
|
+
</ul>
|
|
3114
|
+
|
|
3115
|
+
<p>
|
|
3116
|
+
A third approach consists of pointing to a TimeMap associated with the time-generic resource. A TimeMap, as introduced in the Memento protocol
|
|
3117
|
+
[<a href="#ref-memento">Memento Internet Draft</a>],
|
|
3118
|
+
enables Destinations to retrieve a comprehensive list of all time-specific resources known to a server.
|
|
3119
|
+
This allows Destinations to choose a particular version of a resource from that list.
|
|
3120
|
+
A pointer to a TimeMap is introduced by using an <code><rs:ln></code> element with the following attributes:
|
|
3121
|
+
</p>
|
|
3122
|
+
<ul>
|
|
3123
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>timemap</code>.</li>
|
|
3124
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI of TimeMap associated with the
|
|
3125
|
+
time-generic resource.</li>
|
|
3126
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
3127
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
3128
|
+
</ul>
|
|
3129
|
+
|
|
3130
|
+
<p>
|
|
3131
|
+
<a href="#ex_29">Example 29</a> shows a Change List with a link to a prior version of a
|
|
3132
|
+
resource, a link to a TimeGate, as well as a link to a TimeMap.
|
|
3133
|
+
Note that the values of the <code>hash, length,</code> and <code>type</code> attributes
|
|
3134
|
+
are identical between the <code><rs:md></code> child element and the
|
|
3135
|
+
<code><rs:ln></code> child element that points to the prior version.
|
|
3136
|
+
</p>
|
|
3137
|
+
|
|
3138
|
+
<a name="ex_29"></a>
|
|
3139
|
+
<div class="exampleInner">
|
|
3140
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3141
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3142
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3143
|
+
<rs:ln rel="up"
|
|
3144
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
3145
|
+
<rs:md capability="changelist"
|
|
3146
|
+
from="2013-01-03T00:00:00Z"/>
|
|
3147
|
+
<url>
|
|
3148
|
+
<loc>http://example.com/res1</loc>
|
|
3149
|
+
<lastmod>2013-01-03T18:00:00Z</lastmod>
|
|
3150
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3151
|
+
length="8876"
|
|
3152
|
+
type="text/html"
|
|
3153
|
+
change="updated"/>
|
|
3154
|
+
<rs:ln <span class="rs">rel="memento"</span>
|
|
3155
|
+
href="http://example.com/20130103070000/res1"
|
|
3156
|
+
modified="2013-01-02T18:00:00Z"
|
|
3157
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3158
|
+
length="8876"
|
|
3159
|
+
type="text/html"/>
|
|
3160
|
+
<rs:ln <span class="rs">rel="timegate"</span>
|
|
3161
|
+
href="http://example.com/timegate/http://example.com/res1"/>
|
|
3162
|
+
<rs:ln <span class="rs">rel="timemap"</span>
|
|
3163
|
+
href="http://example.com/timemap/http://example.com/res1"
|
|
3164
|
+
type="application/link-format"/>
|
|
3165
|
+
</url>
|
|
3166
|
+
</urlset>
|
|
3167
|
+
</pre>
|
|
3168
|
+
</div>
|
|
3169
|
+
<p class="caption">Example 29: Links to a resource version, and a Memento TimeGate and TimeMap</p>
|
|
3170
|
+
|
|
3171
|
+
<h3>14.7 <a name="ColMem">Collection Membership</a></h3>
|
|
3172
|
+
<p>
|
|
3173
|
+
A Source may express that a resource is a member of a collection such
|
|
3174
|
+
as an <a href="#ref-oaiore">OAI-ORE</a> Aggregation or an
|
|
3175
|
+
<a href="#ref-oaipmh">OAI-PMH</a> Set.
|
|
3176
|
+
A Source may express collection membership of a resource that is subject to synchronization
|
|
3177
|
+
by providing the URI of that resource in <code><loc></code>, as usual, and by
|
|
3178
|
+
introducing an <code><rs:ln></code> element with the following attributes:
|
|
3179
|
+
</p>
|
|
3180
|
+
<ul>
|
|
3181
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>collection</code>.</li>
|
|
3182
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI that identifies the collection.</li>
|
|
3183
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
3184
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
3185
|
+
</ul>
|
|
3186
|
+
|
|
3187
|
+
<p>
|
|
3188
|
+
<a href="#ex_30">Example 30</a> shows a Change List with one resource that is
|
|
3189
|
+
a member of an OAI-ORE Aggregation.
|
|
3190
|
+
</p>
|
|
3191
|
+
|
|
3192
|
+
<a name="ex_30"></a>
|
|
3193
|
+
<div class="exampleInner">
|
|
3194
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3195
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3196
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3197
|
+
<rs:ln rel="up"
|
|
3198
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
3199
|
+
<rs:md capability="changelist"
|
|
3200
|
+
from="2013-01-03T00:00:00Z"/>
|
|
3201
|
+
<url>
|
|
3202
|
+
<loc>http://example.com/res1</loc>
|
|
3203
|
+
<lastmod>2013-01-03T07:00:00Z</lastmod>
|
|
3204
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3205
|
+
length="8876"
|
|
3206
|
+
type="text/html"
|
|
3207
|
+
change="updated"/>
|
|
3208
|
+
<rs:ln <span class="rs">rel="collection"</span>
|
|
3209
|
+
href="http://example.com/aggregation/0601007"/>
|
|
3210
|
+
</url>
|
|
3211
|
+
</urlset>
|
|
3212
|
+
</pre>
|
|
3213
|
+
</div>
|
|
3214
|
+
<p class="caption">Example 30: A resource as a member of a collection</p>
|
|
3215
|
+
|
|
3216
|
+
<h3>14.8 <a name="RePub">Republishing Resources</a></h3>
|
|
3217
|
+
<p>
|
|
3218
|
+
A special kind of Destination, henceforth called an aggregator,
|
|
3219
|
+
may retrieve content from a Source, republish it, and in its turn
|
|
3220
|
+
act as a Source for the republished content. In such an aggregator
|
|
3221
|
+
scenario, it may be important for a Destination that synchronizes
|
|
3222
|
+
with the aggregator to understand the provenance of the content and
|
|
3223
|
+
to be able to verify its accuracy with the original Source of the
|
|
3224
|
+
content. When communicating about a republished resource, the
|
|
3225
|
+
aggregator may provide such provenance information by introducing
|
|
3226
|
+
an <code><rs:ln></code> element with the following attributes:
|
|
3227
|
+
</p>
|
|
3228
|
+
|
|
3229
|
+
<ul>
|
|
3230
|
+
<li>A mandatory <code>rel</code> attribute with a value of <code>via</code>.</li>
|
|
3231
|
+
<li>A mandatory <code>href</code> attribute that conveys the URI of the resource at the original Source.</li>
|
|
3232
|
+
<li>Other attributes are as described for the <code><rs:ln></code> child element of
|
|
3233
|
+
<code><url></code> in <a href="#DocumentFormats">Section 7</a>.</li>
|
|
3234
|
+
</ul>
|
|
3235
|
+
<p>
|
|
3236
|
+
<a href="#ex_31">Example 31</a> shows a Change List in which a
|
|
3237
|
+
Source publishes information about a change to a single resource.
|
|
3238
|
+
</p>
|
|
3239
|
+
|
|
3240
|
+
<a name="ex_31"></a>
|
|
3241
|
+
<div class="exampleInner">
|
|
3242
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3243
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3244
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3245
|
+
<rs:ln rel="up"
|
|
3246
|
+
href="http://example.com/dataset1/capabilitylist.xml"/>
|
|
3247
|
+
<rs:md capability="changelist"
|
|
3248
|
+
<span class="rs">from="2013-01-03T00:00:00Z"</span>/>
|
|
3249
|
+
<url>
|
|
3250
|
+
<loc><span class="rs">http://original.example.com/res1.html</span></loc>
|
|
3251
|
+
<lastmod><span class="rs">2013-01-03T07:00:00Z</span></lastmod>
|
|
3252
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3253
|
+
length="8876"
|
|
3254
|
+
type="text/html"
|
|
3255
|
+
change="updated"/>
|
|
3256
|
+
</url>
|
|
3257
|
+
</urlset>
|
|
3258
|
+
</pre>
|
|
3259
|
+
</div>
|
|
3260
|
+
<p class="caption">Example 31: An original Source publishes</p>
|
|
3261
|
+
|
|
3262
|
+
<p>
|
|
3263
|
+
<a href="#ex_32">Example 32</a> shows a primary aggregator's Change
|
|
3264
|
+
List that refers to the original Source's resource. It includes a link
|
|
3265
|
+
with the relation type <code>via</code> that has attributes such as
|
|
3266
|
+
<code>href</code> to convey information about the origin of the resource.
|
|
3267
|
+
This information corresponds with the data provided in the
|
|
3268
|
+
<code><url></code> block of the Change List shown in
|
|
3269
|
+
<a href="#ex_31">Example 31</a>. For example, the value of the
|
|
3270
|
+
<code>href</code> attribute in <a href="#ex_32">Example 32</a>
|
|
3271
|
+
equals the value of the <code><loc></code> child element in the
|
|
3272
|
+
<code><url></code> block in <a href="#ex_31">Example 31</a>.
|
|
3273
|
+
</p>
|
|
3274
|
+
|
|
3275
|
+
<a name="ex_32"></a>
|
|
3276
|
+
<div class="exampleInner">
|
|
3277
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3278
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3279
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3280
|
+
<rs:ln rel="up"
|
|
3281
|
+
href="http://aggregator1.example.com/dataset1/capabilitylist.xml"/>
|
|
3282
|
+
<rs:md capability="changelist"
|
|
3283
|
+
<span class="rs">from="2013-01-03T11:00:00Z"</span>/>
|
|
3284
|
+
<url>
|
|
3285
|
+
<loc><span class="rs">http://aggregator1.example.com/res1.html</span></loc>
|
|
3286
|
+
<lastmod><span class="rs">2013-01-03T20:00:00Z</span></lastmod>
|
|
3287
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3288
|
+
length="8876"
|
|
3289
|
+
type="text/html"
|
|
3290
|
+
change="updated"/>
|
|
3291
|
+
<rs:ln <span class="rs">rel="via"</span>
|
|
3292
|
+
href=<span class="rs">"http://original.example.com/res1.html"</span>
|
|
3293
|
+
modified="2013-01-03T07:00:00Z"
|
|
3294
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3295
|
+
length="8876"
|
|
3296
|
+
type="text/html"/>
|
|
3297
|
+
</url>
|
|
3298
|
+
</urlset>
|
|
3299
|
+
</pre>
|
|
3300
|
+
</div>
|
|
3301
|
+
<p class="caption">Example 32: A primary aggregator republishes</p>
|
|
3302
|
+
|
|
3303
|
+
<p>
|
|
3304
|
+
If a secondary aggregator obtains the changed resource by consuming the
|
|
3305
|
+
Change List of the primary aggregator and republishes its Change List,
|
|
3306
|
+
a chain of aggregations is created. In this case each aggregator should
|
|
3307
|
+
maintain only the existing <code>via</code> link in order to convey
|
|
3308
|
+
information about the origin of the resource.
|
|
3309
|
+
</p>
|
|
3310
|
+
<p>
|
|
3311
|
+
<a href="#ex_33">Example 33</a> shows the Change List of a secondary
|
|
3312
|
+
aggregator with information about the changed resource and the
|
|
3313
|
+
<code>via</code> link equal to <a href="#ex_32">Example 32</a>.
|
|
3314
|
+
The data conveyed with the link corresponds to the data provided in the
|
|
3315
|
+
<code><url></code> block in <a href="#ex_31">Example 31</a>.
|
|
3316
|
+
</p>
|
|
3317
|
+
|
|
3318
|
+
<a name="ex_33"></a>
|
|
3319
|
+
<div class="exampleInner">
|
|
3320
|
+
<pre><?xml version="1.0" encoding="UTF-8"?>
|
|
3321
|
+
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
|
|
3322
|
+
xmlns:rs="http://www.openarchives.org/rs/terms/">
|
|
3323
|
+
<rs:ln rel="up"
|
|
3324
|
+
href="http://aggregator2.example.com/dataset1/capabilitylist.xml"/>
|
|
3325
|
+
<rs:md capability="changelist"
|
|
3326
|
+
<span class="rs">from="2013-01-03T12:00:00Z"</span>/>
|
|
3327
|
+
<url>
|
|
3328
|
+
<loc><span class="rs">http://aggregator2.example.com/res1.html</span></loc>
|
|
3329
|
+
<lastmod><span class="rs">2013-01-04T09:00:00Z</span></lastmod>
|
|
3330
|
+
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3331
|
+
length="8876"
|
|
3332
|
+
type="text/html"
|
|
3333
|
+
change="updated"/>
|
|
3334
|
+
<rs:ln <span class="rs">rel="via"</span>
|
|
3335
|
+
href=<span class="rs">"http://original.example.com/res1.html"</span>
|
|
3336
|
+
modified="2013-01-03T07:00:00Z"
|
|
3337
|
+
hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
|
|
3338
|
+
length="8876"
|
|
3339
|
+
type="text/html"/>
|
|
3340
|
+
</url>
|
|
3341
|
+
</urlset>
|
|
3342
|
+
</pre>
|
|
3343
|
+
</div>
|
|
3344
|
+
<p class="caption">Example 33: A second aggregator republishes</p>
|
|
3345
|
+
|
|
3346
|
+
<p>
|
|
3347
|
+
The values of the <code>at</code>, <code>completed</code>,
|
|
3348
|
+
<code>from</code>, and <code>until</code> attributes must always be
|
|
3349
|
+
expressed from the perspective of the Source that publishes the
|
|
3350
|
+
document that contains them. Hence it is possible that the
|
|
3351
|
+
<code>from</code> datetime of a Change List is more recent than
|
|
3352
|
+
the <code><lastmod></code> datetime of the original Source's
|
|
3353
|
+
resource described in the Change List, which is conveyed using an
|
|
3354
|
+
<code><rs:ln></code> link with the <code>via</code> relation type.
|
|
3355
|
+
</p>
|
|
3356
|
+
<p>
|
|
3357
|
+
An aggregator should be cautious when inheriting links, other than the
|
|
3358
|
+
one with the <code>via</code> relation type, from a Source that precedes
|
|
3359
|
+
it in an aggregation chain. It should make sure that each such link remains
|
|
3360
|
+
appropriate from its own perspective and refrain from inheriting it when
|
|
3361
|
+
it is not. For example, a link with the relation type <code>collection</code>
|
|
3362
|
+
or <code>canonical</code> expressed by the original Source may not be
|
|
3363
|
+
appropriate in the context of the aggregator's copy, and hence should not
|
|
3364
|
+
be included in the description of the changed resource in the aggregator's
|
|
3365
|
+
capability document.
|
|
3366
|
+
</p>
|
|
3367
|
+
|
|
3368
|
+
</div> <!--class="body"-->
|
|
3369
|
+
|
|
3370
|
+
<div class="back">
|
|
3371
|
+
<div class="body">
|
|
3372
|
+
|
|
3373
|
+
|
|
3374
|
+
<h2><a name="TimeAttributeReqs"></a>A. Time Attribute Requirements</h2>
|
|
3375
|
+
|
|
3376
|
+
<p><i>(normative)</i></p>
|
|
3377
|
+
|
|
3378
|
+
<p>
|
|
3379
|
+
<a href="#tab_4">Table 4</a> provides an overview of the requirements
|
|
3380
|
+
for use of the <code>at</code> and <code>from</code> attributes
|
|
3381
|
+
in ResourceSync documents.
|
|
3382
|
+
The <i>top</i> label in the column headings represents the <code><sitemapindex></code> root element for index documents, and the
|
|
3383
|
+
<code><urlset></code> root element for all other documents.
|
|
3384
|
+
The <i>child</i> label in the column headings represents the <code><sitemap></code> child element for index documents, and the
|
|
3385
|
+
<code><url></code> child element for all other documents.
|
|
3386
|
+
</p>
|
|
3387
|
+
<p>
|
|
3388
|
+
The optional attributes <code>completed</code> and <code>until</code> are not shown
|
|
3389
|
+
in the table, but they may be added wherever the corresponding <code>at</code> and
|
|
3390
|
+
<code>from</code> attributes are mandatory, recommended, or optional.
|
|
3391
|
+
</p>
|
|
3392
|
+
<p>
|
|
3393
|
+
<a href="#tab_4">Table 4</a> shows that, for example, a Change List must contain the
|
|
3394
|
+
<code><rs:md></code> child element of the <code><urlset></code> root
|
|
3395
|
+
element with the attribute <code>from</code> to convey the temporal
|
|
3396
|
+
interval covered by the Change List. The table also shows that the
|
|
3397
|
+
<code><url></code> child element of the <code><urlset></code> root
|
|
3398
|
+
element in a Change List must have the <code><lastmod></code> child
|
|
3399
|
+
element to convey the last modification time of a resource. Both mandatory
|
|
3400
|
+
attributes are, for example, shown in <a href="#ex_19">Example 19</a> in
|
|
3401
|
+
<a href="#ChangeList">Section 12.1</a>.
|
|
3402
|
+
</p>
|
|
3403
|
+
|
|
3404
|
+
<a name="tab_4"></a>
|
|
3405
|
+
<table class="attr_req_level-table" summary="Time Attribute Requirements">
|
|
3406
|
+
<tbody>
|
|
3407
|
+
<tr class="top">
|
|
3408
|
+
<th>Capability Document</th><th>/<i>top</i>/rs:md/@at</th><th>/<i>top</i>/rs:md/@from</th><th>/<i>top</i>/<i>child</i>/rs:md/@at</th><th>/<i>top</i>/<i>child</i>/rs:md/@from</th><th>/<i>top</i>/<i>child</i>/lastmod</th>
|
|
3409
|
+
</tr>
|
|
3410
|
+
<tr class="odd">
|
|
3411
|
+
<td class="cap">Resource List</td>
|
|
3412
|
+
<td class="mand">Mandatory</td>
|
|
3413
|
+
<td class="na">X</td>
|
|
3414
|
+
<td class="na">X</td>
|
|
3415
|
+
<td class="na">X</td>
|
|
3416
|
+
<td class="opt">Optional</td>
|
|
3417
|
+
</tr>
|
|
3418
|
+
<tr class="odd">
|
|
3419
|
+
<td class="cap">Resource List Index</td>
|
|
3420
|
+
<td class="mand">Mandatory</td>
|
|
3421
|
+
<td class="na">X</td>
|
|
3422
|
+
<td class="opt">Optional</td>
|
|
3423
|
+
<td class="na">X</td>
|
|
3424
|
+
<td class="opt">Optional</td>
|
|
3425
|
+
</tr>
|
|
3426
|
+
<tr class="even">
|
|
3427
|
+
<td class="cap">Resource Dump</td>
|
|
3428
|
+
<td class="mand">Mandatory</td>
|
|
3429
|
+
<td class="na">X</td>
|
|
3430
|
+
<td class="opt">Optional</td>
|
|
3431
|
+
<td class="na">X</td>
|
|
3432
|
+
<td class="opt">Optional</td>
|
|
3433
|
+
</tr>
|
|
3434
|
+
<tr class="even">
|
|
3435
|
+
<td class="cap">Resource Dump Index</td>
|
|
3436
|
+
<td class="mand">Mandatory</td>
|
|
3437
|
+
<td class="na">X</td>
|
|
3438
|
+
<td class="opt">Optional</td>
|
|
3439
|
+
<td class="na">X</td>
|
|
3440
|
+
<td class="opt">Optional</td>
|
|
3441
|
+
</tr>
|
|
3442
|
+
<tr class="even">
|
|
3443
|
+
<td class="cap">Resource Dump Manifest</td>
|
|
3444
|
+
<td class="mand">Mandatory</td>
|
|
3445
|
+
<td class="na">X</td>
|
|
3446
|
+
<td class="na">X</td>
|
|
3447
|
+
<td class="na">X</td>
|
|
3448
|
+
<td class="opt">Optional</td>
|
|
3449
|
+
</tr>
|
|
3450
|
+
<tr class="odd">
|
|
3451
|
+
<td class="cap">Change List</td>
|
|
3452
|
+
<td class="na">X</td>
|
|
3453
|
+
<td class="mand">Mandatory</td>
|
|
3454
|
+
<td class="na">X</td>
|
|
3455
|
+
<td class="na">X</td>
|
|
3456
|
+
<td class="mand">Mandatory</td>
|
|
3457
|
+
</tr>
|
|
3458
|
+
|
|
3459
|
+
<tr class="odd">
|
|
3460
|
+
<td class="cap">Change List Index</td>
|
|
3461
|
+
<td class="na">X</td>
|
|
3462
|
+
<td class="mand">Mandatory</td>
|
|
3463
|
+
<td class="na">X</td>
|
|
3464
|
+
<td class="rec">Recommended</td>
|
|
3465
|
+
<td class="opt">Optional</td>
|
|
3466
|
+
</tr>
|
|
3467
|
+
|
|
3468
|
+
<tr class="even">
|
|
3469
|
+
<td class="cap">Change Dump</td>
|
|
3470
|
+
<td class="na">X</td>
|
|
3471
|
+
<td class="mand">Mandatory</td>
|
|
3472
|
+
<td class="na">X</td>
|
|
3473
|
+
<td class="rec">Recommended</td>
|
|
3474
|
+
<td class="opt">Optional</td>
|
|
3475
|
+
</tr>
|
|
3476
|
+
|
|
3477
|
+
<tr class="even">
|
|
3478
|
+
<td class="cap">Change Dump Index</td>
|
|
3479
|
+
<td class="na">X</td>
|
|
3480
|
+
<td class="mand">Mandatory</td>
|
|
3481
|
+
<td class="na">X</td>
|
|
3482
|
+
<td class="rec">Recommended</td>
|
|
3483
|
+
<td class="opt">Optional</td>
|
|
3484
|
+
</tr>
|
|
3485
|
+
|
|
3486
|
+
<tr class="even">
|
|
3487
|
+
<td class="cap">Change Dump Manifest</td>
|
|
3488
|
+
<td class="na">X</td>
|
|
3489
|
+
<td class="mand">Mandatory</td>
|
|
3490
|
+
<td class="na">X</td>
|
|
3491
|
+
<td class="na">X</td>
|
|
3492
|
+
<td class="mand">Mandatory</td>
|
|
3493
|
+
</tr>
|
|
3494
|
+
</tbody>
|
|
3495
|
+
</table>
|
|
3496
|
+
<p class="caption">Table 4: Required and optional use of <code>at</code> and <code>from</code> attributes in ResourceSync documents</p>
|
|
3497
|
+
|
|
3498
|
+
|
|
3499
|
+
|
|
3500
|
+
<h2>B. <a name="Bibliography">Bibliography</a></h2>
|
|
3501
|
+
|
|
3502
|
+
<p>(This Bibliography is not part of the ResourceSync Framework Specification,
|
|
3503
|
+
ANSI/NISO Z39.99-2014. It is included for information only.)</p>
|
|
3504
|
+
|
|
3505
|
+
<dl>
|
|
3506
|
+
|
|
3507
|
+
<dt>[<a name="ref-arxiv" id="ref-arxiv">arXiv</a>]</dt>
|
|
3508
|
+
<dd><a href="http://arxiv.org/"><cite>arXiv.org</cite></a> [website].
|
|
3509
|
+
Available at: <a href="http://arxiv.org/">http://arxiv.org/</a></dd>
|
|
3510
|
+
|
|
3511
|
+
<dt>[<a name="ref-html-links" id="ref-html-links">HTML Links</a>]</dt>
|
|
3512
|
+
<dd>Raggett, Dave, Arnaud Le Hors, and Ian Jacobs, eds.
|
|
3513
|
+
<a href="http://www.w3.org/TR/html401/struct/links.html"><cite>"Links." Section 12 in: HTML 4.01 Specification</cite></a>.
|
|
3514
|
+
W3C Recommendation. World Wide Web Consortium, December 24, 1999.
|
|
3515
|
+
Available at: <a href="http://www.w3.org/TR/html401/struct/links.html">http://www.w3.org/TR/html401/struct/links.html</a></dd>
|
|
3516
|
+
|
|
3517
|
+
<dt>[<a name="ref-json-patch" id="ref-json-patch">JSON-Patch</a>]</dt>
|
|
3518
|
+
<dd>Bryan, P., and M. Nottingham, eds.
|
|
3519
|
+
<a href="http://tools.ietf.org/html/draft-ietf-appsawg-json-patch"><cite>JSON Patch</cite></a>. Internet Draft.
|
|
3520
|
+
Internet Engineering Task Force (IETF), January 20, 2013.
|
|
3521
|
+
Available at: <a href="http://tools.ietf.org/html/draft-ietf-appsawg-json-patch">http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10</a></dd>
|
|
3522
|
+
|
|
3523
|
+
<dt>[<a name="ref-oaipmh" id="ref-oaipm">OAI-PMH</a>]</dt>
|
|
3524
|
+
<dd>Lagoze, Carl, Herbert Van de Sompel, Michael Nelson, and Simeon Warner, eds.
|
|
3525
|
+
<cite><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html">The Open Archives Initiative Protocol for Metadata Harvesting</a></cite>.
|
|
3526
|
+
Version 2.0. Open Archives Initiative, December 7, 2008.
|
|
3527
|
+
Available at: <a href="http://www.openarchives.org/OAI/openarchivesprotocol.html">http://www.openarchives.org/OAI/openarchivesprotocol.html</a></dd>
|
|
3528
|
+
|
|
3529
|
+
<dt>[<a name="ref-oaiore" id="ref-oaiore">ORE</a>]</dt>
|
|
3530
|
+
<dd>Lagoze, Carl, Herbert Van de Sompel, Pete Johnston, Michael Nelson, Robert Sanderson, and Simeon Warner, eds.
|
|
3531
|
+
<cite><a href="http://www.openarchives.org/ore/datamodel">ORE Specification - Abstract Data Model</a></cite>.
|
|
3532
|
+
Open Archives Initiative, October 17, 2008.
|
|
3533
|
+
Available at: <a href="http://www.openarchives.org/ore/1.0/datamodel">http://www.openarchives.org/ore/1.0/datamodel</a></dd>
|
|
3534
|
+
|
|
3535
|
+
<dt>[<a name="ref-relationtypes" id="ref-relationtype">Relation Types</a>]</dt>
|
|
3536
|
+
<dd>Klein, Martin, Robert Sanderson, Herbert Van de Sompel, Simeon Warner, Graham Klyne, Bernhard Haslhofer, Michael Nelson, and Carl Lagoze, eds.
|
|
3537
|
+
<a href="http://www.openarchives.org/rs/relationtypes"><cite>Relation Types Used in the ResourceSync Framework</cite></a>. Beta draft.
|
|
3538
|
+
Open Archives Initiative, September 27, 2013.
|
|
3539
|
+
Available at: <a href="http://www.openarchives.org/rs/relationtypes">http://www.openarchives.org/rs/relationtypes</a></dd>
|
|
3540
|
+
|
|
3541
|
+
<dt>[<a name="ref-rfc5261" id="ref-rfc5261">RFC 5261</a>]</dt>
|
|
3542
|
+
<dd>Urpalainen, J.
|
|
3543
|
+
<cite><a href="http://www.ietf.org/rfc/rfc5261.txt">An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors. RFC 5261</a></cite>.
|
|
3544
|
+
Internet Engineering Task Force (IETF), September 2008.
|
|
3545
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc5261.txt">http://www.ietf.org/rfc/rfc5261.txt</a></dd>
|
|
3546
|
+
|
|
3547
|
+
<dt>[<a name="ref-rfc5785" id="ref-rfc5785">RFC 5785</a>]</dt>
|
|
3548
|
+
<dd>Nottingham, M., and E. Hammer-Lahav.
|
|
3549
|
+
<cite><a href="http://www.ietf.org/rfc/rfc5785.txt">Defining Well-Known Uniform Resource Identifiers (URIs). RFC 5785</a></cite>.
|
|
3550
|
+
Internet Engineering Task Force (IETF), April 2010.
|
|
3551
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc5785.txt">http://www.ietf.org/rfc/rfc5785.txt</a></dd>
|
|
3552
|
+
|
|
3553
|
+
<dt>[<a name="ref-rfc6596" id="ref-rfc6596">RFC 6596</a>]</dt>
|
|
3554
|
+
<dd>Ohye, M., and J. Kupke.
|
|
3555
|
+
<cite><a href="http://www.ietf.org/rfc/rfc6596.txt">The Canonical Link Relation. RFC 6596</a></cite>.
|
|
3556
|
+
Internet Engineering Task Force (IETF), April 2012.
|
|
3557
|
+
Available at: <a href="http://www.ietf.org/rfc/rfc6596.txt">http://www.ietf.org/rfc/rfc6596.txt</a></dd>
|
|
3558
|
+
|
|
3559
|
+
<dt>[<a name="ref-rsync" id="ref-rsync">rsync</a>]</dt>
|
|
3560
|
+
<dd><cite><a href="http://en.wikipedia.org/wiki/Rsync">rsync</a></cite>.
|
|
3561
|
+
From Wikipedia, the free encyclopedia.
|
|
3562
|
+
Available at: <a href="http://en.wikipedia.org/wiki/Rsync">http://en.wikipedia.org/wiki/Rsync</a></dd>
|
|
3563
|
+
|
|
3564
|
+
<dt>[<a name="ref-webarch" id="ref-webarch">Web Architecture</a>]</dt>
|
|
3565
|
+
<dd>Jacobs, Ian, and Norman Walsh, eds.
|
|
3566
|
+
<a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>.
|
|
3567
|
+
W3C Recommendation. World Wide Web Consortium, December 15, 2004.
|
|
3568
|
+
Available at: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a></dd>
|
|
3569
|
+
|
|
3570
|
+
<dt>[<a name="ref-xhtml-links" id="ref-xhtml-links">XHTML Links</a>]</dt>
|
|
3571
|
+
<dd>McCarron, Shane, et al., eds.
|
|
3572
|
+
<a href="http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule"><cite>"Link Module." Section 5.19 in: XHTML Modularization 1.1. Second Edition</cite></a>.
|
|
3573
|
+
World Wide Web Consortium, July 29, 2010.
|
|
3574
|
+
Available at: <a href="http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule">http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule</a></dd>
|
|
3575
|
+
</dl>
|
|
3576
|
+
|
|
3577
|
+
<h2><a name="FrontMatter"></a>C. Front Matter, Authorship, Acknowledgements</h2>
|
|
3578
|
+
|
|
3579
|
+
<p>(This appendix is contains front matter, authorship and acknowledgements
|
|
3580
|
+
from the PDF version of this specification. They have been moved here to
|
|
3581
|
+
preserve the readability of this web document.)</p>
|
|
3582
|
+
|
|
3583
|
+
<h3>About NISO Standards</h3>
|
|
3584
|
+
|
|
3585
|
+
<p>NISO standards are developed by Working Groups of the National
|
|
3586
|
+
Information Standards Organization. The development process is a strenuous
|
|
3587
|
+
one that includes a rigorous peer review of proposed standards open to each
|
|
3588
|
+
NISO Voting Member and any other interested party. Final approval of the
|
|
3589
|
+
standard involves verification by the American National Standards Institute
|
|
3590
|
+
that its requirements for due process, consensus, and other approval criteria
|
|
3591
|
+
have been met by NISO. Once verified and approved, NISO Standards also become
|
|
3592
|
+
American National Standards.</p>
|
|
3593
|
+
|
|
3594
|
+
<p>These standards may be revised or withdrawn at any time. For current
|
|
3595
|
+
information on the status of this standard contact the NISO office or visit
|
|
3596
|
+
the NISO website at: <a href="http://www.niso.org/">www.niso.org</a>.</p>
|
|
3597
|
+
|
|
3598
|
+
<p>Published by<br/>
|
|
3599
|
+
NISO<br/>
|
|
3600
|
+
3600 Clipper Mill Road<br/>
|
|
3601
|
+
Suite 302<br/>
|
|
3602
|
+
Baltimore, MD 21211<br/>
|
|
3603
|
+
<a href="http://www.niso.org/">www.niso.org</a></p>
|
|
3604
|
+
|
|
3605
|
+
<p>ISSN: 1041-5653 (National Information standards series)<br/>
|
|
3606
|
+
ISBN: 978-1-937522-20-9 (HTML)<br/>
|
|
3607
|
+
ISBN: 978-1-937522-19-3 (PDF)</p>
|
|
3608
|
+
|
|
3609
|
+
<h3>Foreword</h3>
|
|
3610
|
+
|
|
3611
|
+
<p>(This foreword is not part of the ResourceSync Framework Specification,
|
|
3612
|
+
ANSI/NISO Z39.99-2014. It is included for information only.)</p>
|
|
3613
|
+
|
|
3614
|
+
<h4>About This Standard</h4>
|
|
3615
|
+
|
|
3616
|
+
<p>This document is structured as follows:</p>
|
|
3617
|
+
|
|
3618
|
+
<ul>
|
|
3619
|
+
<li><a href="#Walkthrough">Section 1</a>, Introduction, discusses the purpose and scope and provides example use cases and includes a Walkthrough, introducing the core components of the ResourceSync framework by example.</li>
|
|
3620
|
+
<li><a href="#NormativeRefs">Section 2</a>, Normative References, lists references to other standards/specifications that are required for conformance with this standard.</li>
|
|
3621
|
+
<li><a href="#Definitions">Section 3</a>, Definitions, introduces terminology important for the understanding of this standard.</li>
|
|
3622
|
+
<li><a href="#Namespaces">Section 4</a>, Namespace Prefix Bindings, identifies the namespaces used for this specification.</li>
|
|
3623
|
+
<li><a href="#SyncProcesses">Section 5</a>, Synchronization Processes, provides a high-level overview of the various ResourceSync capabilities and shows how these fit in processes aimed at remaining in step with resource changes.</li>
|
|
3624
|
+
<li><a href="#FrameworkOrg">Section 6</a>, Framework Organization, describes the overall organization of the ResourceSync framework: structure, navigation, and discovery.</li>
|
|
3625
|
+
<li><a href="#DocumentFormats">Section 7</a>, Sitemap Document Formats, describes the way in which the document formats introduced by the Sitemap protocol are used to convey synchronization related information in all ResourceSync capabilities.</li>
|
|
3626
|
+
<li><a href="#SourceDesc">Section 8</a>, Describing the Source, and <a href="#CapabilityList">Section 9</a>, Advertising Capabilities, describe how a server should convey the ResourceSync capabilities it supports.</li>
|
|
3627
|
+
<li><a href="#DescResources">Section 10</a>, Describing Resources, <a href="#PackResources">Section 11</a>, Packaging Resources, <a href="#DesChanges">Section 12</a>, Describing Changes, <a href="#PackChanges">Section 13</a>, Packaging Changes, and <a href="#LinkRelRes">Section 14</a>, Linking to Related Resources, each provide details about a capability that a server may implement in order to enable remote systems to remain aligned with its evolving data.</li>
|
|
3628
|
+
<li><a href="#TimeAttributeReqs">Appendix A</a> provides an overview of the requirements for use of the <code>at</code> and <code>from</code> attributes in ResourceSync documents.</li>
|
|
3629
|
+
</ul>
|
|
3630
|
+
|
|
3631
|
+
<h4>Trademarks, Services Marks</h4>
|
|
3632
|
+
|
|
3633
|
+
<p>Wherever used in this standard, all terms that are trademarks or
|
|
3634
|
+
service marks are and remain the property of their respective owners.</p>
|
|
3635
|
+
|
|
3636
|
+
<h4>NISO Voting Members</h4>
|
|
3637
|
+
|
|
3638
|
+
<p>At the time this standard was balloted and approved, the following
|
|
3639
|
+
were members of the NISO Z39.99-201x ResourceSync voting pool:</p>
|
|
3640
|
+
|
|
3641
|
+
<dl>
|
|
3642
|
+
<dt>American Institute of Physics (AIP)</dt>
|
|
3643
|
+
<dd>Evan Owens (primary), Aravind Akella (alternate)</dd>
|
|
3644
|
+
<dt>Los Alamos National Laboratory</dt>
|
|
3645
|
+
<dd>Dianna Magnoni (primary), Herbert Van de Sompel (alternate)</dd>
|
|
3646
|
+
<dt>American Library Association (ALA)</dt>
|
|
3647
|
+
<dd>Nancy Kraft</dd>
|
|
3648
|
+
<dt>Microsoft Corporation</dt>
|
|
3649
|
+
<dd>Alex Wade</dd>
|
|
3650
|
+
<dt>Minitex</dt>
|
|
3651
|
+
<dd>Cecelia Boone (primary), Valerie Horton (alternate), Paul Swanson (alternate)</dd>
|
|
3652
|
+
<dt>American Theological Library Association (ATLA)</dt>
|
|
3653
|
+
<dd>Brenda Bailey-Hainer (primary), Maria Stanton (alternate)</dd>
|
|
3654
|
+
<dt>Music Library Association</dt>
|
|
3655
|
+
<dd>Nara Newcomer (primary), David Sommerfield (alternate)</dd>
|
|
3656
|
+
<dt>Association for Information Science & Technology (ASIS&T)</dt>
|
|
3657
|
+
<dd>Mark Needleman</dd>
|
|
3658
|
+
<dt>National Archives and Records Administration (NARA)</dt>
|
|
3659
|
+
<dd>Laura McCarthy (primary), Marilyn Redman (alternate)</dd>
|
|
3660
|
+
<dt>Association of Research Libraries (ARL)</dt>
|
|
3661
|
+
<dd>Julia Blixrud</dd>
|
|
3662
|
+
<dt>National Federation of Advanced Information Services (NFAIS)</dt>
|
|
3663
|
+
<dd>Marjorie Hlava</dd>
|
|
3664
|
+
<dt>EBSCO Information Services</dt>
|
|
3665
|
+
<dd>Oliver Pesch</dd>
|
|
3666
|
+
<dt>National Library of Finland</dt>
|
|
3667
|
+
<dd>Juha Hakala</dd>
|
|
3668
|
+
<dt>EnvisionWare, Inc.</dt>
|
|
3669
|
+
<dd>Robert Walsh (primary), Michael Monk (alternate)</dd>
|
|
3670
|
+
<dt>National Library of Medicine (NLM)</dt>
|
|
3671
|
+
<dd>Barbara Rapp (primary), Jacque-Lynne Schulman (alternate)</dd>
|
|
3672
|
+
<dt>Ex Libris, Inc.</dt>
|
|
3673
|
+
<dd>Mike Dicus</dd>
|
|
3674
|
+
<dt>OCLC Online Computer Library Center</dt>
|
|
3675
|
+
<dd>Tam Dalrymple (primary), Thomas Hickey (alternate)</dd>
|
|
3676
|
+
<dt>Innovative Interfaces, Inc.</dt>
|
|
3677
|
+
<dd>Brad Jung (primary), John McCullough (alternate)</dd>
|
|
3678
|
+
<dt>SAGE Publications</dt>
|
|
3679
|
+
<dd>Carol Richman</dd>
|
|
3680
|
+
<dt>International DOI Foundation (IDF)</dt>
|
|
3681
|
+
<dd>Norman Paskin</dd>
|
|
3682
|
+
<dt>Scholarly iQ</dt>
|
|
3683
|
+
<dd>Gary Van Overborg (primary), John Milligan (alternate)</dd>
|
|
3684
|
+
<dt>ITHAKA/JSTOR/Portico</dt>
|
|
3685
|
+
<dd>Amy Kirchhoff (primary), Bruce Heterick (alternate)</dd>
|
|
3686
|
+
<dt>Statewide California Electronic Library Consortium (SCELC)</dt>
|
|
3687
|
+
<dd>Rick Burke</dd>
|
|
3688
|
+
<dt>John Wiley & Sons, Ltd.</dt>
|
|
3689
|
+
<dd>Duncan Campbell (primary), Craig Van Dyck (alternate)</dd>
|
|
3690
|
+
<dt>The Library Corporation (TLC)</dt>
|
|
3691
|
+
<dd>Juli Marsh (primary), Wayne Hicks (alternate)</dd>
|
|
3692
|
+
<dt>Library of Congress</dt>
|
|
3693
|
+
<dd>Sally McCallum (primary), John Zagas (alternate)</dd>
|
|
3694
|
+
</dl>
|
|
3695
|
+
|
|
3696
|
+
<h4>NISO D2D Topic Committee</h4>
|
|
3697
|
+
|
|
3698
|
+
<p>At the time NISO approved this standard, the following individuals
|
|
3699
|
+
served on the Discovery to Delivery (D2D) Topic Committee that had
|
|
3700
|
+
oversight for this project.</p>
|
|
3701
|
+
|
|
3702
|
+
<dl>
|
|
3703
|
+
<dt>Kristin Antelman</dt>
|
|
3704
|
+
<dd>North Carolina State University Libraries</dd>
|
|
3705
|
+
<dt>Peter Murray</dt>
|
|
3706
|
+
<dd>Lyrasis</dd>
|
|
3707
|
+
<dt>Pascal Calarco, Co-chair</dt>
|
|
3708
|
+
<dd>University of Waterloo Library</dd>
|
|
3709
|
+
<dt>Tim Shearer</dt>
|
|
3710
|
+
<dd>University of North Carolina Chapel Hill Libraries</dd>
|
|
3711
|
+
<dt>Lucy Harrison, Co-chair</dt>
|
|
3712
|
+
<dd>Florida Virtual Campus</dd>
|
|
3713
|
+
<dt>Christine Stohn</dt>
|
|
3714
|
+
<dd>Ex Libris, Inc.</dd>
|
|
3715
|
+
<dt>Juli Marsh</dt>
|
|
3716
|
+
<dd>The Library Corporation (TLC)</dd>
|
|
3717
|
+
<dt>Chris Shillum</dt>
|
|
3718
|
+
<dd>Reed Elsevier</dd>
|
|
3719
|
+
</dl>
|
|
3720
|
+
|
|
3721
|
+
<h4>NISO ResourceSync Working Group Members</h4>
|
|
3722
|
+
|
|
3723
|
+
<p>The following individuals served on the NISO ResourceSync Working Group,
|
|
3724
|
+
which developed and approved this standard:</p>
|
|
3725
|
+
|
|
3726
|
+
<dl>
|
|
3727
|
+
<dt>Todd Carpenter, Co-chair</dt>
|
|
3728
|
+
<dd>NISO</dd>
|
|
3729
|
+
<dt>Michael Nelson</dt>
|
|
3730
|
+
<dd>Old Dominion University</dd>
|
|
3731
|
+
<dt>Bernhard Haslhofer</dt>
|
|
3732
|
+
<dd>Vienna University of Technology</dd>
|
|
3733
|
+
<dt>Shlomo Sanders</dt>
|
|
3734
|
+
<dd>Ex Libris, Inc.</dd>
|
|
3735
|
+
<dt>Richard Jones</dt>
|
|
3736
|
+
<dd>Cottage Labs</dd>
|
|
3737
|
+
<dt>Robert Sanderson</dt>
|
|
3738
|
+
<dd>Los Alamos National Laboratory</dd>
|
|
3739
|
+
<dt>Martin Klein</dt>
|
|
3740
|
+
<dd>Los Alamos National Laboratory</dd>
|
|
3741
|
+
<dt>Herbert Van de Sompel, Co-chair</dt>
|
|
3742
|
+
<dd>Los Alamos National Laboratory</dd>
|
|
3743
|
+
<dt>Graham Klyne</dt>
|
|
3744
|
+
<dd>University of Oxford</dd>
|
|
3745
|
+
<dt>Paul Walk</dt>
|
|
3746
|
+
<dd>EDINA</dd>
|
|
3747
|
+
<dt>Carl Lagoze</dt>
|
|
3748
|
+
<dd>University of Michigan</dd>
|
|
3749
|
+
<dt>Simeon Warner</dt>
|
|
3750
|
+
<dd>Cornell University</dd>
|
|
3751
|
+
<dt>Stuart Lewis</dt>
|
|
3752
|
+
<dd>JISC Collections</dd>
|
|
3753
|
+
<dt>Zhiwu Xie</dt>
|
|
3754
|
+
<dd>Virginia Tech University Libraries</dd>
|
|
3755
|
+
<dt>Peter Murray</dt>
|
|
3756
|
+
<dd>Lyrasis</dd>
|
|
3757
|
+
<dt>Jeff Young</dt>
|
|
3758
|
+
<dd>OCLC Online Computer Library Center</dd>
|
|
3759
|
+
</dl>
|
|
3760
|
+
|
|
3761
|
+
<h4><a name="Acknowledgments"></a>Acknowledgements</h4>
|
|
3762
|
+
|
|
3763
|
+
<p>This specification is the collaborative work of
|
|
3764
|
+
<a href="http://niso.org/">NISO</a> and the
|
|
3765
|
+
<a href="http://www.openarchives.org/">Open Archives Initiative</a>.
|
|
3766
|
+
Funding for ResourceSync is provided by the
|
|
3767
|
+
<a href="http://www.sloan.org/">Alfred P. Sloan Foundation</a>.
|
|
3768
|
+
UK participation is supported by
|
|
3769
|
+
<a href="http://www.jisc.ac.uk/">Jisc</a>.
|
|
3770
|
+
We also thank numerous individual contributors including: Martin Haye
|
|
3771
|
+
(California Digital Library), David Rosenthal (Stanford University Libraries),
|
|
3772
|
+
Ed Summers (Library of Congress), and Vincent Wehren (Microsoft).</p>
|
|
3773
|
+
|
|
3774
|
+
<div class="Changelog">
|
|
3775
|
+
<h2><a name="Changelog">D. Change Log</a></h2>
|
|
3776
|
+
|
|
3777
|
+
<p>(This appendix is not part of the ResourceSync Framework Specification,
|
|
3778
|
+
ANSI/NISO Z39.99-2014. It is included for information only.)</p>
|
|
3779
|
+
|
|
3780
|
+
<table class="Changelog" summary="Change log">
|
|
3781
|
+
<tbody><tr>
|
|
3782
|
+
<th>Date</th>
|
|
3783
|
+
<th>Editor</th>
|
|
3784
|
+
<th>Description</th>
|
|
3785
|
+
</tr>
|
|
3786
|
+
<tr>
|
|
3787
|
+
<td>2014-04-21</td>
|
|
3788
|
+
<td>martin, herbert, simeon</td>
|
|
3789
|
+
<td>verson 1.0, ANSI/NISO Z39.99-2014</td>
|
|
3790
|
+
</tr>
|
|
3791
|
+
<tr>
|
|
3792
|
+
<td>2013-08-05</td>
|
|
3793
|
+
<td>martin, herbert, rob, simeon</td>
|
|
3794
|
+
<td>version 0.9.1</td>
|
|
3795
|
+
</tr>
|
|
3796
|
+
<tr>
|
|
3797
|
+
<td>2013-06-07</td>
|
|
3798
|
+
<td>martin, herbert, rob, simeon</td>
|
|
3799
|
+
<td>version 0.9</td>
|
|
3800
|
+
</tr>
|
|
3801
|
+
<tr>
|
|
3802
|
+
<td>2013-05-01</td>
|
|
3803
|
+
<td>martin, herbert, rob, simeon</td>
|
|
3804
|
+
<td>version 0.6</td>
|
|
3805
|
+
</tr>
|
|
3806
|
+
<tr>
|
|
3807
|
+
<td>2013-02-01</td>
|
|
3808
|
+
<td>martin, herbert, rob, simeon</td>
|
|
3809
|
+
<td>beta spec draft</td>
|
|
3810
|
+
</tr>
|
|
3811
|
+
<tr>
|
|
3812
|
+
<td>2012-08-13</td>
|
|
3813
|
+
<td>martin, herbert, simeon, bernhard</td>
|
|
3814
|
+
<td>first alpha spec draft</td>
|
|
3815
|
+
</tr>
|
|
3816
|
+
</tbody>
|
|
3817
|
+
</table>
|
|
3818
|
+
</div>
|
|
3819
|
+
|
|
3820
|
+
</div>
|
|
3821
|
+
</div>
|
|
3822
|
+
|
|
3823
|
+
<div id="license">
|
|
3824
|
+
<p><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="img/cc-by-sa-3.0-88x31.png"/></a><br/>This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 Unported License</a>.</p>
|
|
3825
|
+
</div>
|
|
3826
|
+
</body>
|
|
3827
|
+
</html>
|
|
3828
|
+
|
|
3829
|
+
|