@@ -232,6 +232,7 @@ <h2>Introduction</h2>
232
232
233
233
< section id ="conformance ">
234
234
< p > A < a > YAML-LD document</ a > complies with this specification if ...</ p >
235
+ < p class ="ednote "> Define < dfn > YAML-LD document</ dfn > somewhere.</ p >
235
236
236
237
< p > This specification makes use of the following namespace prefixes:</ p >
237
238
< table class ="simple ">
@@ -255,8 +256,8 @@ <h2>Introduction</h2>
255
256
</ tbody >
256
257
</ table >
257
258
258
- < p > These are used within this document as part of a < a > compact IRI</ a >
259
- as a shorthand for the resulting < a > IRI</ a > , such as < code > dcterms:title</ code >
259
+ < p > These are used within this document as part of a < a data-cite =" JSON-LD11#dfn-compact-iri " > compact IRI</ a >
260
+ as a shorthand for the resulting < a data-cite =" rfc3987#section-2 " > IRI</ a > , such as < code > dcterms:title</ code >
260
261
used to represent < code > http://purl.org/dc/terms/title</ code > .</ p >
261
262
</ section >
262
263
@@ -282,9 +283,158 @@ <h2>Interoperability Considerations</h2>
282
283
283
284
</ section >
284
285
286
+ < section class ="appendix normative ">
287
+ < h2 > IANA Considerations</ h2 >
288
+
289
+ < p > This section has been submitted to the Internet Engineering Steering
290
+ Group (IESG) for review, approval, and registration with IANA.</ p >
291
+
292
+ < h3 > application/ld+json</ h3 >
293
+ < dl >
294
+ < dt > Type name:</ dt >
295
+ < dd > application</ dd >
296
+ < dt > Subtype name:</ dt >
297
+ < dd > ld+yaml</ dd >
298
+ < dt > Required parameters:</ dt >
299
+ < dd > N/A</ dd >
300
+ < dt > Optional parameters:</ dt >
301
+ < dd >
302
+ < dl >
303
+ < dt > < code > profile</ code > </ dt >
304
+ < dd >
305
+ < p > A non-empty list of space-separated URIs identifying specific
306
+ constraints or conventions that apply to a YAML-LD document according to [[RFC6906]].
307
+ A profile does not change the semantics of the resource representation
308
+ when processed without profile knowledge, so that clients both with
309
+ and without knowledge of a profiled resource can safely use the same
310
+ representation. The < code > profile</ code > parameter MAY be used by
311
+ clients to express their preferences in the content negotiation process.
312
+ If the profile parameter is given, a server SHOULD return a document that
313
+ honors the profiles in the list which it recognizes,
314
+ and MUST ignore the profiles in the list which it does not recognize.
315
+ It is RECOMMENDED that profile URIs are dereferenceable and provide
316
+ useful documentation at that URI. For more information and background
317
+ please refer to [[RFC6906]].</ p >
318
+ < p > This specification defines seven values for the < code > profile</ code > parameter.</ p >
319
+ < dl >
320
+ < dt > < code > http://www.w3.org/ns/json-ld#expanded</ code > </ dt >
321
+ < dd > To request or specify < a data-cite ="json-ld11#dfn-expanded-document-form "> expanded YAML-LD document form</ a > .</ dd >
322
+ < dt > < code > http://www.w3.org/ns/json-ld#compacted</ code > </ dt >
323
+ < dd > To request or specify < a data-cite ="json-ld11#dfn-compacted-document-form "> compacted YAML-LD document form</ a > .</ dd >
324
+ < dt > < code > http://www.w3.org/ns/json-ld#context</ code > </ dt >
325
+ < dd > To request or specify a < a data-cite ="json-ld11#dfn-context-document "> YAML-LD context document</ a > .</ dd >
326
+ < dt > < code > http://www.w3.org/ns/json-ld#flattened</ code > </ dt >
327
+ < dd > To request or specify < a data-cite ="json-ld11#dfn-flattened-document-form "> flattened YAML-LD document form</ a > .</ dd >
328
+ < dt > < code > http://www.w3.org/ns/json-ld#frame</ code > </ dt >
329
+ < dd > To request or specify a < a data-cite ="json-ld11-framing#dfn-frame "> YAML-LD frame document</ a > .</ dd >
330
+ < dt > < code > http://www.w3.org/ns/json-ld#framed</ code > </ dt >
331
+ < dd > To request or specify < a data-cite ="json-ld11#dfn-framed-document-form "> framed YAML-LD document form</ a > .</ dd >
332
+ < dt > < code > http://www.w3.org/ns/json-ld#extended</ code > </ dt >
333
+ < dd > To request or specify < a data-lt ="extended document form "> extended YAML-LD document form</ a > .
334
+ < div class ="ednote ">
335
+ This is a placeholder for specifying something like an
336
+ < dfn data-lt ="extended-document-form "> extended YAML-LD document form</ dfn >
337
+ making use of YAML-specific features.
338
+ </ div > </ dd >
339
+ </ dl >
340
+ < p > All other URIs starting with < code > http://www.w3.org/ns/json-ld</ code >
341
+ are reserved for future use by JSON-LD specifications.</ p >
342
+ <!--p>Other specifications MAY create further structured subtypes
343
+ by using `+ld+json` as a suffix for a new base subtype, as in
344
+ `application/example+ld+json`.
345
+ Unless defined otherwise, such subtypes use the same
346
+ fragment identifier behavior as `application/ld+json`.</p-->
347
+ < p > Other specifications may publish additional `profile` parameter
348
+ URIs with their own defined semantics.
349
+ This includes the ability to associate a file extension with a `profile` parameter.</ p >
350
+ < p >
351
+ When used as a < a data-cite ="RFC4288#section-4.3 "> media type parameter</ a > [[RFC4288]]
352
+ in an < a data-cite ="rfc7231#rfc.section.5.3.2 "> HTTP Accept header</ a > [[RFC7231]],
353
+ the value of the < code > profile</ code > parameter MUST be enclosed in quotes (< code > "</ code > ) if it contains
354
+ special characters such as whitespace, which is required when multiple profile URIs are combined.</ p >
355
+ < p > When processing the "profile" media type parameter, it is important to
356
+ note that its value contains one or more URIs and not IRIs. In some cases
357
+ it might therefore be necessary to convert between IRIs and URIs as specified in
358
+ < a data-cite ="RFC3986#section-5.1 "> section 3 Relationship between IRIs and URIs</ a >
359
+ of [[RFC3987]].</ p >
360
+ </ dd >
361
+ </ dl >
362
+ </ dd >
363
+ < dt > Encoding considerations:</ dt >
364
+ < dd > See < a data-cite ="RFC8259#section-11 "> RFC 8259, section 11</ a > .</ dd >
365
+ < dt id ="iana-security "> Security considerations:</ dt >
366
+ < dd > See < a data-cite ="RFC8259#section-12 "> RFC 8259, section 12</ a > [[RFC8259]]
367
+ < p > When processing YAML-LD documents, links to remote contexts and frames are
368
+ typically followed automatically, resulting in the transfer of files
369
+ without the explicit request of the user for each one. If remote
370
+ contexts are served by third parties, it may allow them to gather
371
+ usage patterns or similar information leading to privacy concerns.
372
+ Specific implementations, such as the API defined in the
373
+ JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11-API]],
374
+ may provide fine-grained mechanisms to control this behavior.</ p >
375
+ < p > YAML-LD contexts that are loaded from the Web over non-secure connections,
376
+ such as HTTP, run the risk of being altered by an attacker such that
377
+ they may modify the YAML-LD < a data-cite ="json-ld11#dfn-active-context "> active context</ a > in a way that
378
+ could compromise security. It is advised that any application that
379
+ depends on a remote context for mission critical purposes vet and
380
+ cache the remote context before allowing the system to use it.</ p >
381
+ < p > Given that YAML-LD allows the substitution of long IRIs with short terms,
382
+ YAML-LD documents may expand considerably when processed and, in the worst case,
383
+ the resulting data might consume all of the recipient's resources. Applications
384
+ should treat any data with due skepticism.</ p >
385
+ < p > As YAML-LD places no limits on the IRI schemes that may be used,
386
+ and vocabulary-relative IRIs use string concatenation rather than
387
+ IRI resolution, it is possible to construct IRIs that may be
388
+ used maliciously, if dereferenced.</ p >
389
+ </ dd >
390
+ < dt > Interoperability considerations:</ dt >
391
+ < dd > Not Applicable</ dd >
392
+ < dt > Published specification:</ dt >
393
+ < dd > http://www.w3.org/TR/yaml-ld</ dd >
394
+ < dt > Applications that use this media type:</ dt >
395
+ < dd > Any programming environment that requires the exchange of
396
+ directed graphs. Implementations of YAML-LD have been created for
397
+ < span class ="note "> FIXME</ span > .
398
+ </ dd >
399
+ < dt > Additional information:</ dt >
400
+ < dd >
401
+ < dl >
402
+ < dt > Magic number(s):</ dt >
403
+ < dd > Not Applicable</ dd >
404
+ < dt > File extension(s):</ dt >
405
+ < dd > .yamlld</ dd >
406
+ < dt > Macintosh file type code(s):</ dt >
407
+ < dd > TEXT</ dd >
408
+ </ dl >
409
+ </ dd >
410
+ < dt > Person & email address to contact for further information:</ dt >
411
+ < dd > Philippe Le Hégaret <
[email protected] >
</ dd >
412
+ < dt > Intended usage:</ dt >
413
+ < dd > Common</ dd >
414
+ < dt > Restrictions on usage:</ dt >
415
+ < dd > N/A</ dd >
416
+ < dt > Author(s):</ dt >
417
+ < dd > ...</ dd >
418
+ < dt > Change controller:</ dt >
419
+ < dd > W3C</ dd >
420
+ </ dl >
421
+
422
+ < section id ="iana-examples " class ="informative ">
423
+ < h3 > Examples</ h3 >
424
+ < p class ="ednote "> FIXME</ p >
425
+ </ section >
426
+ </ section >
427
+
285
428
< section id ="int " class ="informative ">
286
429
< h2 > Fragment identifiers</ h2 >
287
430
431
+ < p > Fragment identifiers used with < a href ="#application-ld-json "> application/ld+json</ a >
432
+ are treated as in RDF syntaxes, as per
433
+ < a data-cite ="RDF11-CONCEPTS#section-fragID "> RDF 1.1 Concepts and Abstract Syntax</ a >
434
+ [[RDF11-CONCEPTS]].
435
+ < div class ="ednote "> Perhaps more on fragment identifiers from < span class ="issue " data-number ="13 "> </ span > </ div >
436
+ </ p >
437
+
288
438
< p >
289
439
YAML media type support both alias nodes and JSON Pointers [[RFC6905]]
290
440
as fragment identifiers (see [[I-D.httpapi-yaml-mediatypes]]).
@@ -296,5 +446,5 @@ <h2>Fragment identifiers</h2>
296
446
297
447
</ section >
298
448
299
- </ body >
449
+ </ body >
300
450
</ html >
0 commit comments