RE: [xri-comment] My Feedback for XRD Vrsion 1.0

[Eran Hammer-Lahav <eran@hueniverse.com>]

First, it is not anyone's fault (other than your own) that your posts, across multiple lists, are a bucket full of crazy. I am not referring to your technical arguments, no matter how incoherent and incorrect, but to the rants and curses aimed at anyone who either doesn't understand or doesn't agree with your posts. It also didn't help that some of the people who answered your rants on the OpenID list had no understanding of XRD (or what you were saying). If it wasn't so counterproductive, it would make a hysterical off-off-broadway satire about the art of creating standards.

Second, I am only responding to this latest installment because it is time to put an end to it, and because the OASIS process requires that all comments be addressed (we don't have to agree with them, but we cannot ignore them). 

You would probably find it useful to read this:

http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality

> -----Original Message-----
> From: Santosh Rajan [mailto:santrajan@gmail.com]
> Sent: Sunday, November 08, 2009 6:52 AM

> What makes a Resource a "Resource"? Or what makes any "thing" or an "entity" a Resource?
> It is the "availability" of the Resource to something else (another entity).

You don't get to make up your very own web architecture and terminology. If you are going to use terms like 'resource', 'entity', 'available', you better use normative references to define what they mean, because your prose leaves me scratching my head. But even using the English meaning of these terms, this is patently false. XRD uses the common web architecture definition of a resource, and fully subscribes to the following text in RFC 3986:

      This specification does not limit the scope of what might be a
      resource; rather, the term "resource" is used in a general sense
      for whatever might be identified by a URI.  Familiar examples
      include an electronic document, an image, a source of information
      with a consistent purpose (e.g., "today's weather report for Los
      Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
      collection of other resources.  A resource is not necessarily
      accessible via the Internet; e.g., human beings, corporations, and
      bound books in a library can also be resources.  Likewise,
      abstract concepts can be resources, such as the operators and
      operands of a mathematical equation, the types of a relationship
      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
      one, and infinity).

XRD was intentionally designed to describe a single resource because that is the common use case driving its development. To support this use case, XRD provides the <Subject> element which requires an absolute URI value. An XRD with a <Subject> means it is a descriptor for the resource identified by that URI. And contrary to the common misunderstanding, <Alias> elements do not extend the scope of an XRD but merely provide other URIs the *subject* resource may be known as. In other words, <Subject> describes the single URI the XRD is about, while <Alias> describe the resource identified by <Subject>. They are fundamentally different elements.

For example (using names instead of URIs to make a point):

<XRD>
	<Subject>Joe</Subject>
	<Alias>Joseph</Subject>
</XRD>

Means: "This XRD is about Joe, who is also known as Joseph". It DOES NOT mean: "This XRD is about Joe, but also about Joseph".

The TC was also aware that this view (of a single URI subject) might be too limited in other cases (such as host-meta). However, we opted not to define a mechanism to support other such subjects (other descriptor specifications such as POWDER made a different choice) because of lack of strong use cases. For this reason, we defined <Subject> as optional because we designed it to accommodate a very specific design. This is not a matter of opinion but definition. An XRD with a <Subject> element is defined as describing a single, URI-identified resource.

This wasn't done on a whim but after a year-long discussion (all publically documented in the XRI TC archives). At some point we included a 'match' attribute on the <Subject> element to allow defining a pattern for a set of resources. Based on the TC own mantra of only including features with strong use cases, and based on feedback received from other communities, we decided to drop this feature.

If you want to use XRD to describe something other than "A single resource identified by a URI", you are free to extend the schema and define some other mechanism to describe what your XRD is about. We provided <Subject> to cover what we consider to be the most common use case. YMMV.

When faced with this limitation, some people have suggested to make <Subject> a string instead of a URI. While this will solve the URI limitation, it will introduce an interoperability challenge. URIs provide a clearly namespaces resource-identifier-space. If the subject can be any string, we need to figure out what that string means. This can be done using:

1. Another property such as <Subject type="uri"> or <Subject type="host"> which will then require establishing a registry for type values. This offers no real benefits over simply defining other elements for other subject types but it does increase the document complexity for the common case.
2. The context in which an XRD is found. While valid, it takes away from the usefulness of XRD, by making it unable to self-describe what it is about. If the method through which an XRD is obtained defines its meaning (and that is likely to be the case in some protocols), a self-contained XRD is unable to assert its own scope. It also poses trust challenge because it is usually a bad idea to sign a document which doesn't explicitly includes its purpose or scope.

After considering all the options, we decided to define a single <Subject> element with well defined meaning and semantics. We think it will be useful in most use cases, and when not, protocols are free to replace it with something else, either internally or externally.

As for host-meta, it is defined as a document about a host or list of hosts (as defined by RFC 3986). At this time, there is no URI available to define such an abstract resource, and even if there was, host-meta needs to define multiple hosts for deployment reasons (example.com redirects to www.example.com). This too was discussed for a long time. We considered using DNS URIs (but they identify a DNS *record* not what the record means), URNs (which are not really appropriate for URIs with some form of authority, or an appealing choice for many web developers), a new URI scheme for host: (not likely to win community support), a well-known URI prefix (such as http://host-meta.net/http://example.com), the URI of the host-meta document itself (which would present a paradox), and a few other ideas. There is simply no appropriate URI to describe what host-meta is about.

We decided that the host-meta use case was not sufficient to change the XRD spec. Instead, host-meta defines its own <Host> element.

EHL