Internet Engineering Task Force L. Svensson
Internet-Draft Deutsche Nationalbibliothek
Intended status: Standards Track R. Verborgh
Expires: January 12, 2020 Ghent University – imec
July 11, 2019

Indicating and Negotiating Profiles in HTTP
draft-svensson-content-profile-00

Abstract

This document defines two new HTTP headers "Content-Profile" and "Accept-Profile" that enable User Agents and servers to indicate and negotiate the profile used for representing a specific resource. In this context, a profile is a description of structural and/or semantic constraints on representations of documents in addition to the syntactical interpretation provided by their MIME type. Examples of profiles include Dublin Core Application Profiles, XML Schemata, and RDF Shape Expressions. This document further defines the "profile" attribute for the HTTP "Link" header and suggests a best practice for the use of the new headers together with the "Link" header for the purposes of performing content negotiation and pointing clients to alternate representations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 12, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

This document defines two new HTTP headers that enable User Agents and servers to indicate and negotiate the profile used for representing a specific resource. On the Web, resources are identified with HTTP(S) URIs. It can be useful for a server to provide multiple representations of a resource to accommodate different User Agents or use cases. When a User Agent issues a GET request for a specific URI, the User Agent and the server negotiate which of the available representations best suit the User Agent's needs and capabilities. Typically, a User Agent specifies preferences by setting appropriate HTTP headers, e.g., "Accept" for media type, "Accept-Language" for content language, or "Accept-Charset" for character encoding.

1.1. Motivation

In many cases, there are several ways to describe a resource within the scope of a media type. In the case of XML documents, for instance, the same content can be encoded using one of several DTDs or XML Schemas. JSON documents similarly leave open a wide range of options regarding which tree structure, keys, and value types to use. In RDF, there is a wide choice of vocabularies available to describe resources of the same kind. However, when a User Agent initiates a request, e.g., a GET request to retrieve or a PUT request to create or replace a resource, neither the User Agent nor the server have any possibility to exchange information on how the transmitted resource is or needs to be formatted precisely beyond the media type. This document therefore proposes a solution by defining the HTTP headers "Content-Profile" and "Accept-Profile".

1.2. Terminology

In this context, a profile is a description of structural and/or semantic constraints on representations of documents in addition to the syntactical interpretation provided by their MIME type. Examples of a profile in this context include, but are not limited to, Dublin Core application profiles (formally expressed in Description Set Profiles (DSP)), XML Schema documents, and RDF Shapes expressed in SHACL. Profiles can, but do not need to, be independent of a media type. The definition and usage of profiles in applications is beyond the scope of this proposal; our only constraint is that a profile is identified by a URI. Further assumptions about profiles, e. g. hierarchies of profiles, inheritance or transitivity, are out of this specification's scope.

Typical use cases for profiles include validation, and building clients that rely on additional assumptions in a representation received from another system. These assumptions, such as the presence of a certain structure or certain fields, are currently often implicitly made, or documented out of band, whereas profiles can explicitly capture them. The choice of the term "profile" was derived from the term "Application Profile", which the Dublin Core community defines as "schemas which consist of data elements drawn from one or more namespaces, combined together by implementers, and optimised for a particular local application" [HeeryAndPatel].

1.3. High-level overview of solution

The proposed solution introduces two new HTTP header fields: "Content-Profile" and "Accept-Profile". With "Content-Profile", a sender of a message can indicate the profile(s) to which it knows the enclosed representation conforms. With "Accept-Profile", a potential recipient of a message can indicate its preference for receiving representations that conform to (a) certain profile(s). An agent can specify several profiles and use quality indicators (q-values) to indicate preferences.

A server that supports profiles can then list one or more profiles in the "Content-Profile" header in its response specifying the profile or profiles the returned payload conforms to. The specified list of profiles may not be exhaustive since the returned content can conform to profiles that the server is not aware of. If multiple representations of the same resource are available, and those conform to different profiles, the server can use a "Link" header field together with the "profile" attribute to point an agent to those other representations.

Similarly, an agent sending information to a server, e.g., by using PUT or POST, can include a "Content-Profile" header field in the HTTP request to state which profile or profiles the request payload conforms to. Prior to that interaction, the target server can include an "Accept-Profile" header field in a response to indicate which profiles the resource is willing to accept in payloads from PUT/POST/PATCH requests.

Note that this information is specific to the current request; the set of supported profiles might be different for other resources on the same server and/or could change over time.

The absence of an "Accept-Profile" header field in an HTTP response SHOULD be taken as an indication that the server does not support profile-based content-negotiation for the given resource. It MUST NOT be seen as an indication that the server can handle payloads conforming to any profile.

A server that fails a request due to receiving a payload with an unsupported profile SHOULD respond with a 415 status and SHOULD include an "Accept-Profile" header in its response, allowing clients to distinguish between issues related to profiles and media types. In order to avoid confusion with issues related to media types, servers that fail a request with a 415 status for reasons unrelated to profiles MUST NOT include the "Accept-Profile" header field.

1.4. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Related HTTP Headers

2.1. Content-Type

The "Content-Type" HTTP header is used to indicate the media type of a representation. This header allows receipients to determine appropriate processing for a received message body, such as the parser they need to use. A "Content-Type" field value contains a MIME type, such as "text/html" or "application/json," and can optionally have parameters, such as "charset".

In many current interactions, senders of HTTP messages underspecify the MIME type of their messages. They opt for common, generic media types such as "text/xml" or "application/json," whereas the contents of their messages actually implicitly conform to stricter assumptions. These assumptions are communicated out of band and then silently (if at all) implemented by recipients. Because those assumptions are not specified explicitly, clients cannot discover them at runtime to adjust their processing accordingly. Minting new media types is possible, but this loses the formal relationship with the generic media type, which would need to be specified out of band.

application/activity+json

application/ld+json; profile="https://www.w3.org/ns/activitystreams"

The "profile" parameter can be used in the "Content-Type" field in addition to a MIME type to indicate a media-type-specific profile the representation conforms to. Such profiles are often defined within the specification of document formats. For instance, Activity Streams 2.0 defines the following equivalent media types: "+json" suffix as a non-binding suggestion that the content conforms to "application/json", and such an indicator does not exist for JSON-LD and most other media types. As such, those clients are not informed about their possible ability to parse a message body as JSON or JSON-LD. Clients that do have support for "application/activity+json" will likely need to involve JSON and JSON-LD parsers regardless.

The need to mint specific media types for profiles becomes a combinatorial issue when profiles can apply to multiple media types, or when representations can conform to multiple profiles. This document introduces a solution by considering profiles as an additional, independent dimension in content negotiation.

2.2. Accept

The "Accept" header is the counterpart of the "Content-Type" header. Whereas "Content-Type" indicates the option the sender has chosen for representing the message body, "Accept" communicates the recipient's representation preferences beforehand.

The value of an "Accept" header field is a comma-separated list of MIME types, each of which can optionally have parameters. The "q" parameter is a number between 0.0 and 1.0 indicating the degree of preference for that MIME type. Analogously to the "Content-Type" field, the "profile" parameter can be used to indicate a preference for a media-type-specific profile.

2.3. Content-Location

GET /some/resource HTTP/1.1
Accept: application/ld+json;
        profile="https://www.w3.org/ns/activitystreams"
HTTP/1.1 200 OK
Content-Type: application/ld+json;
              profile="https://www.w3.org/ns/activitystreams"
Content-Location: /some/resource.as.jsonld

The "Content-Location" header can be used to provide an identifier for the specific representation of a resource that is enclosed in the message body. For example, when a User Agent issues the following request for /some/resource:

2.4. Link

The "Link" header allows the sender of a message to model additional relationships from the represented resource to others. Such relations are expressed as a link to a target with a relation type and, optionally, target attributes. Of particular interest for content negotiation are the self and alternate relation types, whose targets identify respectively the current representation and other existing representations. The "Link" header can thereby serve as a mechanism for discovering supported representations and profiles. The "profile" relation type can be used to relate a representation to a profile to which it conforms.

The "self" relation type overlaps with the functionality provided by the Content-Location field, and they will likely use the same identifier. The "alternate" relation essentially provides Content-Location functionality for other available representations. Finally, the "profile" relation type mimics the "profile" parameter in the "Content-Type" field, except that conformance of a representation to multiple profiles could be expressed through multiple "profile" links, whereas "Content-Type" only accepts one "profile" parameter.

3. New HTTP Headers

The "Content-Profile" and "Accept-Profile" header fields MAY be sent by both the User Agent and the server. The "Content-Profile" header contains a non-exhaustive list of profiles the payload of the message conforms to, whereas the "Accept-Profile" header specifies one or more profiles the Agent accepts. For example, a User Agent issuing a request for a resource could specify through the "Accept" header that it accepts representations with either text/turtle or application/ld+json as MIME type, and through the "Accept-Profile" header that it prefers people to be described using the FOAF vocabulary, but that the BBC Core ontology is also acceptable. When the server answers, it would set the "Content-Type" and "Content-Profile" header fields appropriately. Likewise, a User Agent sending an XML document with a specific structure to a server could set the "Content-Type" and the "Content-Profile" header fields. If the server cannot process the specified profile, it would answer with an HTTP 415 status code and possibly a list of acceptable profiles.

The "Accept-Profile" and "Content-Profile" header MUST use a URI to refer to a profile. That URI MAY point to an actual document, or if the parties involved agree on a profile definition, MAY be e.g. a URN or an info-URI. When a protocol-based URI is used, such as an FTP- or an HTTP-URI, however, it SHOULD dereference to a document containing that profile's definition.

3.1. Content-Profile Header Syntax

The "Content-Profile" header field specifies one or more profiles the payload in the message conforms to. In absence of a "Content-Profile" header, the User Agent SHOULD NOT make any assumptions about the representation beyond what is specified by the media type indicated in the "Content-Type" header.

If a "Content-Profile" field is present, it MUST contain a comma-separated list of profile URIs. Each profile MUST be identified by an absolute URI reference inside angle brackets ("<>"). The recipient SHOULD interpret this list as an indication that the payload of the message conforms to all of the profiles identified by the supplied profile URIs. Differences in ordering of the items in this list, or the presence of duplicates, MUST NOT be interpreted as semantically significant. Instead of sending a comma-separated list of profile URIs in one "Content-Profile" header field, and agent MAY choose to send each profile URI in its own "Content-Profile" header field without changing its meaning, as specified in Section 3.2.2 of RFC 7230.

If a User Agent uses the "Content-Profile" header field to indicate the profile the payload conforms to (e.g., in an HTTP POST or PUT request) and the server can only process content in other profiles, the server SHOULD respond with a 415 status code together with an "Accept-Profile" header field (including q-values) to indicate which profiles it supports.

Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in RFC 5234 and the rules defined in Section 3.2 of RFC 7230. The definition of "URI-reference" is imported from RFC 7230.

Profile header syntax

Content-Profile = "Content-Profile" ":"
                OWS "<" URI-reference ">"
                *(OWS "," OWS "<" URI-reference ">") OWS

Figure 1

3.2. Accept-Profile Header Syntax

The "Accept-Profile" header field specifies one or more content profiles the issuing agent accepts for processing. If an "Accept-Profile" field is present, it MUST contain a comma-separated list of profile URIs. Each profile MUST be identified by an absolute URI reference inside angle brackets ("<>"). Quality values as defined in Section 5.3.1 of RFC 7230 MAY be used to assign a relative "weight" to the preference. Exactly how that weight is used to determine the best representation is beyond the scope of this specification.

A request without "Accept-Profile" header field SHOULD indicate that the recipient accepts content conforming to any profile. If the header field is present in a User Agent request and the server cannot provide a representation that conforms to the specified profile, it SHOULD either honor the header field by responding with a 406 (Not Acceptable) status code, or disregard the header field by treating the response as if it is not subject to content negotiation. If the server does not support profile-based content negotiation, the latter behavior SHOULD also be followed. Regardless of the outcomes of the negotiation process, if the server knows that the representation conforms to one or more profiles, it SHOULD list them in the "Content-Profile" header of the response.

The absence of an "Accept-Profile" header field in an HTTP response SHOULD be taken as an indication that the server does not support profiles for the given resource. It MUST NOT be seen as an indication that the server handles payloads conforming to any profile.

An agent that wants to indicate that several profiles are acceptable, can either submit one Accept-Profile field for every profile that is acceptable (possibly specifying q-values for each profile URI) or it can decide to combine all profile URIs into a comma-separated list and send that list in a single Accept-Profile field. Differences in ordering of the items in this list, or the presence of duplicates, MUST NOT be interpreted as semantically significant. Instead of sending a comma-separated list of profile URIs in one "Accept-Profile" header field, and agent MAY choose to send each profile URI in its own "Content-Profile" header field without changing its meaning, as specified in Section 3.2.2 of RFC 7230.

Figure 2 describes the syntax (Augmented Backus-Naur Form) of the Accept-Profile header fields, using the grammar defined in RFC 5234 and the rules defined in Section 3.2 of RFC 7230. The definitions of "URI-reference" and "weight" are imported from RFC 7230 and RFC 7231, respectively.

Accept-Profile header syntax

Accept-Profile = "Accept-Profile" ":"
               OWS (profile-value) *(OWS "," OWS profile-value) OWS
profile-value = "<" URI-reference ">" [weight]

Figure 2

4. Content Negotiation

4.1. Mechanisms

User Agents and servers supporting profiles can agree on mutually acceptable profiles for the payload through the content negotiation processes described in Section 3.4 of RFC 7231. The present document does not define or alter content negotiation, but rather adds an additional dimension to the content negotiation process. Agents can indicate their preferences for certain profiles by specifying an "Accept-Profile" header on requests, and servers indicate their choice by specifying a "Content-Profile" header on responses. Both proactive negotiation and reactive negotiation for profiles can be supported by servers.

Although servers are free to implement negotiation as they see fit, if the User Agent sends an "Accept-Profile" header, they SHOULD consider representations not conforming to any of the listed profiles as non-interpretable by the client. This means that a representation that conforms to a listed profile, but has a low preference score on other dimensions, SHOULD be considered as more desired than a representation with a higher preference score on other dimensions but that does not conform to any listed profile. If no "Accept-Profile" header preference is given, the profile dimension SHOULD be ignored for negotiation purposes. Nonetheless, in all cases, the server's response SHOULD contain a "Content-Profile" header listing the URIs of all profiles to which it knows the representation conforms.

A server that fails a request due to receiving a payload with an unsupported profile SHOULD respond with a 415 status and SHOULD include an "Accept-Profile" header in its response, allowing clients to distinguish between issues related to profiles and media types. In order to avoid confusion with issues related to media types, servers that fail a request with a 415 status for reasons unrelated to profiles MUST NOT include the "Accept-Profile" header field.

4.2. Examples

The following examples show possible exchanges of profile information between a User Agent and a server. For clarity, the examples only contain minimal information, i.e., only the relevant headers are included and message bodies are ignored.

In this first example, a User Agent requests a JSON representation. The server returns a JSON representation, and indicates that it conforms to additional structural constraints as specified in a profile identified by "urn:example:schema:e-commerce-payment". Based on this information, the client can choose to use a JSON parser, and can rely on additional assumptions about the structure and semantics of the resulting JSON tree.

Request:

  GET /document HTTP/1.1
  Accept: application/json

Response:

  HTTP/1.1 200 OK
  Content-Type: application/json
  Content-Profile: <urn:example:schema:e-commerce-payment>

Figure 3

Another User Agent requests a JSON representation conforming to additional constraints, as specified in a profile identified by "urn:example:schema:e-commerce-payment". The server has such a representation of the resource available, as well as an XML representation conforming to the same profile, and another JSON representation conforming to a different profile.

Request:
  GET /document HTTP/1.1
  Accept: application/json
  Accept-Profile: <urn:example:schema:e-commerce-payment>

Response:
  HTTP/1.1 200 OK
  Content-Type: application/json
  Content-Profile: <urn:example:schema:e-commerce-payment>
  Link: rel="self";
          type="application/json";
          profile="urn:example:schema:e-commerce-payment",
        rel="alternate";
          type="application/xml";
          profile="urn:example:schema:e-commerce-payment;",
        rel="alternate";
          type="application/json";
          profile="urn:example:schema:e-commerce-accounting"

Figure 4

A User Agent requests an RDF document conforming to one of two RDF Shapes. It uses q-values to express a preference for shape-1. The server, however, prefers to deliver in shape-2, and the response also happens to conform to shape-3.

Request:
  GET /document HTTP/1.1
  Accept: text/turtle, application/rdf+xml
  Accept-Profile: <http://example.com/shapes/shape-1>;q=0.8,
                  <http://example.com/shapes/shape-2>;q=0.5

Response:
  HTTP/1.1 200 OK
  Content-Type: text/turtle
  Content-Profile: <http://example.com/shapes/shape-2>,
                   <http://example.com/shapes/shape-3>
  Link: rel="self";
          type="text/turtle";
          profile="http://example.com/shapes/shape-2
                   http://example.com/shapes/shape-3",
        rel="alternate";
          type="text/turtle";
          profile="http://example.com/shapes/shape-4"

Figure 5

A User Agent requests an RDF document conforming to one of two RDF Shapes. The server, however, does not support these profiles.

Request:
  GET /document HTTP/1.1
  Accept: text/turtle, application/rdf+xml
  Accept-Profile: <http://example.com/shapes/shape-1>;q=0.8,
                  <http://example.com/shapes/shape-2>;q=0.5

Response:
  HTTP/1.1 406 Not Acceptable
  Content-Type: text/html
  Link: rel="alternate";
          type="text/turtle";
          profile="http://example.com/shapes/shape-4"

Figure 6

A User Agent PUTs an RDF document conforming to the RDF Shape identified by http://example.com/shapes/shape-1. The server answers that it can only process documents conforming to http://example.com/shapes/shape-2. The User Agent knows the problem is caused by the profile, because the "Accept-Profile" header is listed.

Request:
  PUT /document HTTP/1.1
  Content-Type: text/turtle
  Content-Profile: <http://example.com/shapes/shape-1>

Response:
  HTTP/1.1 415 Unsupported Media Type
  Content-Type: text/html
  Accept-Profile: <http://example.com/shapes/shape-2>

Figure 7

5. IANA Considerations

This specification defines two header field for the Hypertext Transfer Protocol (HTTP) that have been registered with the Internet Assigned Numbers Authority (IANA) following the "Registration Procedures for Message Header Fields" RFC 3864. [TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/message-headers/message-headers.xhtml] Further, it defines an attribute for the "Link" header. There is no registry for "link-param" except for the values listed in RFC 8288 so the attribute "profile" will be seen as a link-extension.

5.1. Accept-Profile HTTP Header Registration

The Accept-Profile header should be added to the permanent registry of message header fields (see RFC 3864), taking into account the guidelines given by HTTP/1.1 RFC 7231.

Header Field Name: Accept-Profile

Applicable Protocol: Hypertext Transfer Protocol (HTTP)

Status: Informational

Author/Change controller: IETF

Specification document(s): RFC XXXX

5.2. Content-Profile HTTP Header Registration

The Content-Profile header should be added to the permanent registry of message header fields (see RFC 3864), taking into account the guidelines given by HTTP/1.1 RFC 7231.

Header Field Name: Content-Profile

Applicable Protocol: Hypertext Transfer Protocol (HTTP)

Status: Informational

Author/Change controller: IETF

Specification document(s): RFC XXXX

6. Definition of the Link header target attribute "profile"

When used in a Link header field, the "profile" attribute is a hint indicating which profile the resource representation retrieved by dereferencing the link conforms to. Note that this is only a hint; for example it does not override the "Content-Profile" header field of a HTTP response obtained by actually following the link. Multiple "profile" attributes on a single link value indicate that the resource representation conforms to multiple profiles.

The ABNF for the profile attribute's value is:

absolute-URI

where "absolute-URI" is defined as in section 4.3 of RFC 3986.

7. Security Considerations

The use of HTTP to negotiate and transport profile information implies that all privacy and security issues that are relevant for that protocol are also relevant for profile negotiation. E. g., information such as user agent, accept-headers, IP address etc. can potentially be used as identifying information, and particularly, the IP address adds information about geolocation and institutional membership. Further, offering a list of acceptable profiles at the beginning of a negotiation process can reveal information about the user's interests that could be used to add such information to a user profile. If this is undesirable, a client and/or a server can stop exposing the header, in which case HTTP interactions would be back to the level of standard HTTP (i.e., with no indication what profiles the User Agent or the server prefer and/or can handle).

8. Acknowledgements

This is the place to have YOUR NAME prominently displayed!

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014.

9.2. Informative References

[DSP] Nilsson, M., "Description Set Profiles: A constraint language for Dublin Core Application Profiles", 2008.
[HeeryAndPatel] Heery, R. and M. Patel, "Application Profiles: Mixing and Matching Metadata Schemas", 2000.
[RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004.
[RFC4452] Van de Sompel, H., Hammond, T., Neylon, E. and S. Weibel, "The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces", RFC 4452, DOI 10.17487/RFC4452, April 2006.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013.
[RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, DOI 10.17487/RFC6906, March 2013.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017.
[W3C.REC-activitystreams-core-20170523] Snell, J. and E. Prodromou, "Activity Streams 2.0", World Wide Web Consortium Recommendation REC-activitystreams-core-20170523, May 2017.
[W3C.REC-shacl-20170720] Knublauch, H. and D. Kontokostas, "Shapes Constraint Language (SHACL)", World Wide Web Consortium Recommendation REC-shacl-20170720, July 2017.
[W3C.REC-xmlschema11-1-20120405] Gao, S., Sperberg-McQueen, M., Thompson, H., Mendelsohn, N., Beech, D. and M. Maloney, "W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures", World Wide Web Consortium Recommendation REC-xmlschema11-1-20120405, April 2012.

Authors' Addresses

Lars G. Svensson Deutsche Nationalbibliothek Adickesallee 1 Frankfurt, 60322 Germany Phone: +49 69 1525 1752 EMail: l.svensson@dnb.de
Ruben Verborgh Ghent University – imec Sint-Pietersnieuwstraat 41 Ghent, 9000 Belgium Phone: +32 9 331 49 10 EMail: ruben.verborgh@ugent.be