DAP4: URL Annotations - Revision history

DennisHeimbigner: /* Annotation Mechanisms */

2012-02-26T21:08:08Z

Annotation Mechanisms

← Older revision		Revision as of 21:08, 26 February 2012
Line 63:		Line 63:
	# URL fragment -- everything after the last '#'. Again these are pretty much free form.		# URL fragment -- everything after the last '#'. Again these are pretty much free form.
	# Filename extensions -- everything between the data set name in the path and the start of the query. The DAP2 ".dds" and ".dods" are examples of this.		# Filename extensions -- everything between the data set name in the path and the start of the query. The DAP2 ".dds" and ".dods" are examples of this.
	# <ins>Alternate extension formats. Ethan Davis has proposed the use of a "+" notation instead of filename extensions: +ddx+ascii, for example. This has the advantage of clearly not being confused with filename extensions while also making clear the additive nature of such annotation.<ins>		# <ins>Alternate extension formats. Ethan Davis has proposed the use of a "+" notation instead of filename extensions: +ddx+ascii, for example. This has the advantage of clearly not being confused with filename extensions while also making clear the additive nature of such annotation.</ins>

	I should note that the Ferret server has taken to seriously abusing the URL format with URLs like this.		I should note that the Ferret server has taken to seriously abusing the URL format with URLs like this.

DennisHeimbigner at 21:07, 26 February 2012

2012-02-26T21:07:26Z

← Older revision		Revision as of 21:07, 26 February 2012
Line 1:		Line 1:
			[Most recent modifications are either underlined or struck out]

	== Characterization of URL Annotations ==		== Characterization of URL Annotations ==

Line 18:		Line 20:
	# Data requests with format: ".dods", ".asc"		# Data requests with format: ".dods", ".asc"
	# Miscellaneous: ".html", ".ver"		# Miscellaneous: ".html", ".ver"

	~~[Most recent modifications are either underlined or struck out]~~

	=== Client commands ===		=== Client commands ===
Line 62:		Line 62:
	# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.		# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.
	# URL fragment -- everything after the last '#'. Again these are pretty much free form.		# URL fragment -- everything after the last '#'. Again these are pretty much free form.
	# ~~filename~~ extensions -- everything between the data set name in the path and the start of the query. The DAP2 ".dds" and ".dods" are examples of this.		# Filename extensions -- everything between the data set name in the path and the start of the query. The DAP2 ".dds" and ".dods" are examples of this.
			# <ins>Alternate extension formats. Ethan Davis has proposed the use of a "+" notation instead of filename extensions: +ddx+ascii, for example. This has the advantage of clearly not being confused with filename extensions while also making clear the additive nature of such annotation.<ins>

	I should note that the Ferret server has taken to seriously abusing the URL format with URLs like this.		I should note that the Ferret server has taken to seriously abusing the URL format with URLs like this.

DennisHeimbigner: /* Client commands */

2012-02-25T21:20:54Z

Client commands

← Older revision		Revision as of 21:20, 25 February 2012
Line 35:		Line 35:
	One notable problem with this form of client command is that it prevented generic URL parsers from parsing the URL because, of course, the square bracket notation is non-standard.		One notable problem with this form of client command is that it prevented generic URL parsers from parsing the URL because, of course, the square bracket notation is non-standard.

	<ins>An alternative to using client commands in the URL is to use a configuration file (often referred to as the ''.rc'' file such as ''.dodsrc''. This configuration file is assumed to be either in the caller's home directory or in the current working directory. It contains the necessary client commands to be applied. It is mildly less convenient for the user to use a .rc file than to embed a client command in the URL.		<ins>An alternative to using client commands in the URL is to use a configuration file (often referred to as the ''.rc'' file such as ''.dodsrc''). This configuration file is assumed to be either in the caller's home directory or in the current working directory. It contains the necessary client commands to be applied. It is mildly less convenient for the user to use a .rc file than to embed a client command in the URL.
	</ins>		</ins>

DennisHeimbigner: /* Client commands */

2012-02-25T21:19:56Z

Client commands

← Older revision		Revision as of 21:19, 25 February 2012
Line 29:		Line 29:
	# <ins>Caching - control the degree of caching and prefetch to be used with a given request to the server.</ins>		# <ins>Caching - control the degree of caching and prefetch to be used with a given request to the server.</ins>

	Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[~~sequencesize=10~~]", for example. These commands are prefixed to the URL such as this.		Currently, client commands are represented as "name=value" pairs or just "name" enclosed in square braces: "[nocache]", for example. These commands are prefixed to the URL such as this.
	[~~sequencesize~~=10]http://test.opendap.org/dataset.nc		[show=fetch]http://test.opendap.org/dataset.nc
	The legal set of command is library specific.		The legal set of command is library specific.

DennisHeimbigner: /* Client commands */

2012-02-25T21:18:26Z

Client commands

← Older revision		Revision as of 21:18, 25 February 2012
Line 18:		Line 18:
	# Data requests with format: ".dods", ".asc"		# Data requests with format: ".dods", ".asc"
	# Miscellaneous: ".html", ".ver"		# Miscellaneous: ".html", ".ver"

			[Most recent modifications are either underlined or struck out]

	=== Client commands ===		=== Client commands ===
Line 23:		Line 25:
	Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.		Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.

	<ins>Currently, there are two primary uses for client commands.		<ins>Currently, there are two primary uses for client commands.</ins>
	# Debugging - cause the DAP library to output information about, for example, the specific requests it sends to the server.		# <ins>Debugging - cause the DAP library to output information about, for example, the specific requests it sends to the server.</ins>
	# Caching - control the degree of caching and prefetch to be used with a given request to the server.</ins>		# <ins>Caching - control the degree of caching and prefetch to be used with a given request to the server.</ins>

	Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.		Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.

DennisHeimbigner at 21:14, 25 February 2012

2012-02-25T21:14:17Z

← Older revision		Revision as of 21:14, 25 February 2012
Line 23:		Line 23:
	Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.		Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.

	Currently, there are two primary uses for client commands.		<ins>Currently, there are two primary uses for client commands.
	# Debugging - cause the DAP library to output information about, for example, the specific requests it sends to the server.		# Debugging - cause the DAP library to output information about, for example, the specific requests it sends to the server.
	# Caching - control the degree of caching and prefetch to be used with a given request to the server.		# Caching - control the degree of caching and prefetch to be used with a given request to the server.</ins>

	Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.		Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.
Line 32:		Line 32:

	One notable problem with this form of client command is that it prevented generic URL parsers from parsing the URL because, of course, the square bracket notation is non-standard.		One notable problem with this form of client command is that it prevented generic URL parsers from parsing the URL because, of course, the square bracket notation is non-standard.

			<ins>An alternative to using client commands in the URL is to use a configuration file (often referred to as the ''.rc'' file such as ''.dodsrc''. This configuration file is assumed to be either in the caller's home directory or in the current working directory. It contains the necessary client commands to be applied. It is mildly less convenient for the user to use a .rc file than to embed a client command in the URL.
			</ins>

	=== Queries ===		=== Queries ===

DennisHeimbigner at 21:09, 25 February 2012

2012-02-25T21:09:39Z

← Older revision		Revision as of 21:09, 25 February 2012
Line 22:		Line 22:

	Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.		Client commands are interpreted by the client-side library to specify actions to be performed by the library. The existence of client commands is important because we want to communicate from the user to the library without requiring any knowledge by intermediate code layers. For example, netcdf C tools such as ncdump sends URLs to the underlying netcdf DAP2 library without having to be cognizant of their structure.

			Currently, there are two primary uses for client commands.
			# Debugging - cause the DAP library to output information about, for example, the specific requests it sends to the server.
			# Caching - control the degree of caching and prefetch to be used with a given request to the server.

	Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.		Currently, client commands are represented as "name=value" pairs enclosed in square braces: "[sequencesize=10]", for example. These commands are prefixed to the URL such as this.

DennisHeimbigner: /* Protocol = */

2012-02-21T01:05:39Z

Protocol =

← Older revision		Revision as of 01:05, 21 February 2012
Line 7:		Line 7:
	Looking at the DAP2 URLs, we see three classes of annotations: protocol, server commands, client commands, and queries (aka constraints).		Looking at the DAP2 URLs, we see three classes of annotations: protocol, server commands, client commands, and queries (aka constraints).

	=== Protocol ====		=== Protocol ===
	For DAP2, the fact that the protocol being used is inferred from context; in netcdf-C, for example, the fact that the dataset name is a URL is sufficient to indicate the use of the DAP2 protocol. For some servers, such as TDS, the protocol is also inferrable from elements of the URL path. For example, in http://.../thredds/dodsC/... the "dodsC" indicates the use of the DAP2 protocol. TDS also supports a schema called "dods:" that also indicates the use of DAP2.		For DAP2, the fact that the protocol being used is inferred from context; in netcdf-C, for example, the fact that the dataset name is a URL is sufficient to indicate the use of the DAP2 protocol. For some servers, such as TDS, the protocol is also inferrable from elements of the URL path. For example, in http://.../thredds/dodsC/... the "dodsC" indicates the use of the DAP2 protocol. TDS also supports a schema called "dods:" that also indicates the use of DAP2.

DennisHeimbigner: /* Characterization of URL Annotations */

2012-02-21T01:05:16Z

Characterization of URL Annotations

← Older revision		Revision as of 01:05, 21 February 2012
Line 5:		Line 5:
	This document is intended to just describe the information with which URLs need to annotated based on past experience. It also enumerates the possible URL components that can be used to encode the annotations. I will consider a specific encoding in a separate document.		This document is intended to just describe the information with which URLs need to annotated based on past experience. It also enumerates the possible URL components that can be used to encode the annotations. I will consider a specific encoding in a separate document.

	Looking at the DAP2 URLs, we see three classes of annotations: server commands, client commands, and queries (aka constraints).		Looking at the DAP2 URLs, we see three classes of annotations: protocol, server commands, client commands, and queries (aka constraints).

			=== Protocol ====
			For DAP2, the fact that the protocol being used is inferred from context; in netcdf-C, for example, the fact that the dataset name is a URL is sufficient to indicate the use of the DAP2 protocol. For some servers, such as TDS, the protocol is also inferrable from elements of the URL path. For example, in http://.../thredds/dodsC/... the "dodsC" indicates the use of the DAP2 protocol. TDS also supports a schema called "dods:" that also indicates the use of DAP2.

	=== Server Commands ===		=== Server Commands ===
Line 46:		Line 49:

	As mechanisms, we have the following available to us:		As mechanisms, we have the following available to us:
	# The URL schema -- http: for example, or the TDS dods: schema. Using this is somewhat undesirable because it would need to encode also an underlying encrypted protocol like https: (versus http:).		# The URL schema -- "http:" for example, or the TDS "dods:" schema. Using this is somewhat undesirable because it would need to encode also an underlying encrypted protocol like https: (versus http:).
	# URL path elements such as the current use of e.g. http://host/../dodsC/... by TDS.		# URL path elements such as the current use of e.g. http://host/../dodsC/... by TDS.
	# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.		# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.

DennisHeimbigner: /* Characterization of URL Annotations */

2012-02-20T21:26:03Z

Characterization of URL Annotations

← Older revision		Revision as of 21:26, 20 February 2012
Line 46:		Line 46:

	As mechanisms, we have the following available to us:		As mechanisms, we have the following available to us:
			# The URL schema -- http: for example, or the TDS dods: schema. Using this is somewhat undesirable because it would need to encode also an underlying encrypted protocol like https: (versus http:).
	# URL path elements such as the current use of e.g. http://host/../dodsC/... by TDS.		# URL path elements such as the current use of e.g. http://host/../dodsC/... by TDS.
	# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.		# URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form.