diff --git a/spec/index.html b/spec/index.html index 275d936..ab6dae6 100644 --- a/spec/index.html +++ b/spec/index.html @@ -17,7 +17,7 @@ }], // Cross-reference definitions - xref: ["json-ld11", "json-ld11-api", "json-ld11-framing"], + //xref: ["json-ld11", "json-ld11-api", "json-ld11-framing"], group: "cg/json-ld", wgPublicList: "public-linked-json", @@ -215,6 +215,7 @@

Introduction

A YAML-LD document complies with this specification if ...

+

Define YAML-LD document somewhere.

This specification makes use of the following namespace prefixes:

@@ -238,8 +239,8 @@

Introduction

-

These are used within this document as part of a compact IRI - as a shorthand for the resulting IRI, such as dcterms:title +

These are used within this document as part of a compact IRI + as a shorthand for the resulting IRI, such as dcterms:title used to represent http://purl.org/dc/terms/title.

@@ -248,5 +249,155 @@

Basic Concepts

FIXME.

+ +
+

IANA Considerations

+ +

This section has been submitted to the Internet Engineering Steering + Group (IESG) for review, approval, and registration with IANA.

+ +

application/ld+json

+
+
Type name:
+
application
+
Subtype name:
+
ld+yaml
+
Required parameters:
+
N/A
+
Optional parameters:
+
+
+
profile
+
+

A non-empty list of space-separated URIs identifying specific + constraints or conventions that apply to a YAML-LD document according to [[RFC6906]]. + A profile does not change the semantics of the resource representation + when processed without profile knowledge, so that clients both with + and without knowledge of a profiled resource can safely use the same + representation. The profile parameter MAY be used by + clients to express their preferences in the content negotiation process. + If the profile parameter is given, a server SHOULD return a document that + honors the profiles in the list which it recognizes, + and MUST ignore the profiles in the list which it does not recognize. + It is RECOMMENDED that profile URIs are dereferenceable and provide + useful documentation at that URI. For more information and background + please refer to [[RFC6906]].

+

This specification defines seven values for the profile parameter.

+
+
http://www.w3.org/ns/json-ld#expanded
+
To request or specify expanded YAML-LD document form.
+
http://www.w3.org/ns/json-ld#compacted
+
To request or specify compacted YAML-LD document form.
+
http://www.w3.org/ns/json-ld#context
+
To request or specify a YAML-LD context document.
+
http://www.w3.org/ns/json-ld#flattened
+
To request or specify flattened YAML-LD document form.
+
http://www.w3.org/ns/json-ld#frame
+
To request or specify a YAML-LD frame document.
+
http://www.w3.org/ns/json-ld#framed
+
To request or specify framed YAML-LD document form.
+
http://www.w3.org/ns/json-ld#extended
+
To request or specify extended YAML-LD document form. +
+ This is a placeholder for specifying something like an + extended YAML-LD document form + making use of YAML-specific features. +
+
+

All other URIs starting with http://www.w3.org/ns/json-ld + are reserved for future use by JSON-LD specifications.

+ +

Other specifications may publish additional `profile` parameter + URIs with their own defined semantics. + This includes the ability to associate a file extension with a `profile` parameter.

+

+ When used as a media type parameter [[RFC4288]] + in an HTTP Accept header [[RFC7231]], + the value of the profile parameter MUST be enclosed in quotes (") if it contains + special characters such as whitespace, which is required when multiple profile URIs are combined.

+

When processing the "profile" media type parameter, it is important to + note that its value contains one or more URIs and not IRIs. In some cases + it might therefore be necessary to convert between IRIs and URIs as specified in + section 3 Relationship between IRIs and URIs + of [[RFC3987]].

+
+
+
+
Encoding considerations:
+
See RFC 8259, section 11.
+
Security considerations:
+
See RFC 8259, section 12 [[RFC8259]] +

When processing YAML-LD documents, links to remote contexts and frames are + typically followed automatically, resulting in the transfer of files + without the explicit request of the user for each one. If remote + contexts are served by third parties, it may allow them to gather + usage patterns or similar information leading to privacy concerns. + Specific implementations, such as the API defined in the + JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11-API]], + may provide fine-grained mechanisms to control this behavior.

+

YAML-LD contexts that are loaded from the Web over non-secure connections, + such as HTTP, run the risk of being altered by an attacker such that + they may modify the YAML-LD active context in a way that + could compromise security. It is advised that any application that + depends on a remote context for mission critical purposes vet and + cache the remote context before allowing the system to use it.

+

Given that YAML-LD allows the substitution of long IRIs with short terms, + YAML-LD documents may expand considerably when processed and, in the worst case, + the resulting data might consume all of the recipient's resources. Applications + should treat any data with due skepticism.

+

As YAML-LD places no limits on the IRI schemes that may be used, + and vocabulary-relative IRIs use string concatenation rather than + IRI resolution, it is possible to construct IRIs that may be + used maliciously, if dereferenced.

+
+
Interoperability considerations:
+
Not Applicable
+
Published specification:
+
http://www.w3.org/TR/yaml-ld
+
Applications that use this media type:
+
Any programming environment that requires the exchange of + directed graphs. Implementations of YAML-LD have been created for + FIXME. +
+
Additional information:
+
+
+
Magic number(s):
+
Not Applicable
+
File extension(s):
+
.yamlld
+
Macintosh file type code(s):
+
TEXT
+
+
+
Person & email address to contact for further information:
+
Philippe Le Hégaret <plh@w3.org>
+
Intended usage:
+
Common
+
Restrictions on usage:
+
N/A
+
Author(s):
+
...
+
Change controller:
+
W3C
+
+ +

Fragment identifiers used with application/yaml+json + are treated as in RDF syntaxes, as per + RDF 1.1 Concepts and Abstract Syntax + [[RDF11-CONCEPTS]]. +

Perhaps more on fragment identifiers from
+

+ +
+

Examples

+

FIXME

+
+
+