Internet DRAFT - draft-wilde-template-desc
draft-wilde-template-desc
Network Working Group E. Wilde
Internet-Draft C. Davis
Intended status: Standards Track EMC Corporation
Expires: June 10, 2013 Y. Liu
UC Berkeley
December 7, 2012
URI Template Descriptions
draft-wilde-template-desc-00
Abstract
Interactions with many resources on the Web are driven by and/or can
be described by URI Templates. RFC 6570 says that "a URI Template is
a compact sequence of characters for describing a range of Uniform
Resource Identifiers through variable expansion." This specification
defines Template Descriptions, a schema and a media type that can be
used to document and describe a URI Template by supporting
descriptive markup that allows variables to be associated with
documentation (human-oriented) and/or descriptions (machine-
oriented). Template Descriptions can be used by media types (by
inclusion or by reference) that seek to make URI Templates self-
describing, without having to create their own representation.
Note to Readers
Please discuss this draft on the rest-discuss mailing list [9].
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 http://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 June 10, 2013.
Copyright Notice
Wilde, et al. Expires June 10, 2013 [Page 1]
Internet-Draft URI Template Descriptions December 2012
Copyright (c) 2012 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. URI Template . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Describing Variables . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Template Descriptions . . . . . . . . . . . . . . . . . . . . . 5
3.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 5
3.2. Template Description Structure . . . . . . . . . . . . . . 5
3.3. Variable Description Structure . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. OpenSearch . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Atom Feeds . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Wilde, et al. Expires June 10, 2013 [Page 2]
Internet-Draft URI Template Descriptions December 2012
1. Introduction
Simple interactions with resources on the Web often are driven by
simply following links, but in many other cases, interactions with
resources require clients to provide information in addition to just
using a fixed URI in a request. In these cases, information can
provided in any way supported by the interaction protocol, and in
case of HTTP, this often means that information is either embedded in
the URI, and/or in the body of the request. For the first case, the
"URI Template" standard Section 1.1 provides a standard that allows
servers and clients to exchange information about the URIs that a
service accepts.
1.1. URI Template
The "URI Template" standard RFC 6570 [1] specifies "a compact
sequence of characters for describing a range of Uniform Resource
Identifiers through variable expansion." It allows servers to
publish their expectation how a URI should be created by substituting
variables with values. Consider the following URI Template:
http://www.example.com/feed{?pagesize,page}
This URI Template allows clients to expand two variables to end up
with a concrete URI such as the following:
http://www.example.com/feed?pagesize=10&page=42
URI Templates cover the aspect of starting with a template with
variables in it, assigning values to these variables, and then
expanding the template into a URI that can be used for sending a
request. URI Templates make no assumptions or statements about the
value range of the variables, except for those aspects which are
required to cover the process of expanding the template. In
particular, for the example given above, there is no indication that
the values are supposed to be positive integers (the simple data
type), nor is there any indication that the service may apply certain
limits such as a maximum page size (which may change depending on
which paged resource is being accessed). As a side note, even if
this information was known, URI template expansion could still result
in URIs that would not yield successful requests, such as when asking
for a page that is beyond the number of pages that a feed has (in a
given page size).
The goal of Templates Descriptions as defined here is to allow
servers to expose a description resource that provides support both
at development time (when a developer looks at a media type that uses
URI Templates) and at runtime (when a client wants to use a URI
template as part of its application flow).
Wilde, et al. Expires June 10, 2013 [Page 3]
Internet-Draft URI Template Descriptions December 2012
1.2. Describing Variables
Variables can be described in a variety of ways when using Template
Descriptions. For each variable in the URI Template, it is possible
to use the following description methods:
Domain Concept: It is possible to associate a variable with a
domain concept, so that media types and applications can make an
association between the concepts they are defining/exposing, and
where they are represented in URI Tenplates. Concepts can be
referred to by URI, or by using a QName [2].
Datatype: Variables can be described in terms of using certain
datatypes, and the datatype vocabulary is that of XML Schema Part
2 [3], plus all of the applicable facets of those datatypes. This
allows Template Descriptions to constrain the set of allowed
values.
Documentation: Documentation constructs can be associated with
variables, which allows Template Descriptions to attach human-
readable information to individual variables. The documentation
constructs use the documentation design of XML Schema Part 1 [4].
Application Information: Application information constructs can be
associated with variables, which allows Template Descriptions to
attach machine-readable information to individual variables. The
application information constructs use the application information
design of XML Schema Part 1 [4].
For the purpose of this specification, the term "description" should
be interpreted loosely. Some aspects of descriptions can be formal,
such as the datatypes of variables. Thus, such a description can be
used to drive general-purpose logic that knows nothing but this
specification. However, for most other description aspects (domain
concepts, documentation, and application information), this
specification does not prescribe a description framework; it simply
provides a structure how to deliver these descriptions.
2. Terminology
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 [5].
Wilde, et al. Expires June 10, 2013 [Page 4]
Internet-Draft URI Template Descriptions December 2012
3. Template Descriptions
Template Descriptions are based on a URI Template, and add
descriptive elements that allow publishers of URI Templates to
describe the URI Template as a whole, and to add individual
descriptions of all variables in the template.
3.1. General Concepts
As mentioned in Section 1.1, most of the descriptions in this spec to
not prescribe a specific description framework. While variables
(Section 3.3) can be described with a built-in vocabulary of
datatypes, most other descriptions are either for human consumption,
or do rely on some external description framework. To attach these
descriptions to both the template as a whole, and individual
variables, this specification reuses the "appinfo" and
"documentation" elements from XML Schema Part 1 [4]. These elements
carry a "source" attribute which is used (quoting from [4]) "to
supplement the local information."
3.2. Template Description Structure
A template is described by including the URI Template itself, and
optionally adding documentation and/or appinfo elements to add human-
or machine-readable descriptions.
3.3. Variable Description Structure
A variable is described by specifying the variable name. Variables
can refer to a "concept" associated with a variable, which can by
identified by URI, or by a QName (at most one of these SHALL be
present). This specification makes no provision how such a concept
is defined or described, but it allows consumers of a Template
Description to match their understanding of certain concepts to those
identifiers, which then establishes a binding between the concept,
and the variable it has been bound to.
Variable descriptions can optionally add documentation and/or appinfo
elements to add human- or machine-readable descriptions.
4. IANA Considerations
4.1. Media Type
The Internet media type for a Template Description document is
application/td+xml.
Wilde, et al. Expires June 10, 2013 [Page 5]
Internet-Draft URI Template Descriptions December 2012
Type name: application
Subtype name: td+xml
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: See Security Considerations in Section 5.
Interoperability considerations: N/A
Published specification: [[ This document ]]
Applications that use this media type: Applications that publish
descriptions of URI Templates.
Additional information:
Magic number(s): N/A
File extension(s): .tdx
Macintosh file type code(s): TEXT
Person & email address to contact for further information: Erik
Wilde <erik.wilde@emc.com>
Intended usage: COMMON
Restrictions on usage: none
Author: Erik Wilde <erik.wilde@emc.com>
Change controller: IETF
4.2. Link Relation
The link relation type below will be registered by IANA per Section
6.2.1 of RFC 5988 [6]:
Relation Name: query-template
Description: Linking to a resource that can be used as a template
description for creating a request URI for the context resource.
Wilde, et al. Expires June 10, 2013 [Page 6]
Internet-Draft URI Template Descriptions December 2012
Reference: [[ This document ]]
Notes: Template Descriptions can be used in all scenarios where
clients want to create requests that represent a query into the
context resource. The media type of the context resource and the
media type of the template description resource are not
constrained by this specification.
5. Security Considerations
...
6. Examples
...
6.1. OpenSearch
...
6.2. Atom Feeds
...
"Feed Paging and Archiving" specified in RFC 5005 [8]
Maybe suggest to use profiles?
7. Open Issues
If and how to use profiles (example in Section 6); if profile use
is recommended, define a suggested profile URI for other specs to
use?
Should we support other ways how URIs could be generated, most
importantly the application/x-www-form-urlencoded method of HTML
forms?
How to handle variables in Level 4 templates that are supposed to
have composite values?
Should there be some way how default values can be exposed/
documented?
Wilde, et al. Expires June 10, 2013 [Page 7]
Internet-Draft URI Template Descriptions December 2012
If a template is refined in an incremental process, does it make
sense to be able to add a "back" link and/or "home" link, so that
clients can find the "most general" version easily?
8. References
8.1. Normative References
[1] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D.
Orchard, "URI Template", RFC 6570, March 2012.
[2] Hollander, D., Layman, A., Thompson, H., Tobin, R., and T. Bray,
"Namespaces in XML 1.0 (Third Edition)", World Wide Web
Consortium Recommendation REC-xml-names-20091208, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[3] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
Edition", World Wide Web Consortium Recommendation REC-
xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[4] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML
Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[7] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
8.2. Informative References
[8] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
September 2007.
URIs
[9] <http://tech.groups.yahoo.com/group/rest-discuss/>
Wilde, et al. Expires June 10, 2013 [Page 8]
Internet-Draft URI Template Descriptions December 2012
Authors' Addresses
Erik Wilde
EMC Corporation
6801 Koll Center Parkway
Pleasanton, CA 94566
U.S.A.
Phone: +1-925-6006244
Email: erik.wilde@emc.com
URI: http://dret.net/netdret/
Cornelia Davis
EMC Corporation
Email: cornelia.davis@emc.com
Yiming Liu
UC Berkeley
South Hall
Berkeley, CA 94720
U.S.A.
Email: yliu@ischool.berkeley.edu
Wilde, et al. Expires June 10, 2013 [Page 9]
