Re: URI references and aggregation

Ted,

I apologize for taking so long to respond to this.  If I understand you 
correctly, you are proposing that:

(1) There is an IANA-allocated URL associated (in a well defined fashion) 
with every registered (IETF-tree and global-tree) feature tag.  The data 
resource at this URL would be a copy of the feature registration template.

(2) [At the definer's discretion] the URI part of an unregistered feature 
tag can be used in similar fashion as a URL to retrieve information about 
the feature.

(3) Use a URL to name an aggregate, with the aggregate expression being the 
referenced resource.

(4) Allow a defined form of URN (or a URI that is not a URL) to represent a 
hash-based aggregate name.

The motivation for this, I understand, is to have a uniform approach for 
dealing with unknown features, and unknown aggregates.

I see a number of possible problems here:

(a) unless a URL can always be resolved to a machine-interpretable 
definition, I think there there is marginal value in having a uniform 
resolution machinery.  If the expectation is that an aggregate URL resolves 
to an interpretable expression, it may be better if simple feature tag URIs 
are not resolvable, since there is generally no corresponding machine 
interpretable expression.  Also, there is a syntactic difference between 
usage of feature tags and aggregate names (i.e. auxiliary predicate vs 
comparison forms), though it might be possible to finesse that in some way.

(b) the unregistered feature tag form is defined as using URI syntax, not 
limited to being a URL.  So a mechanism for resolution is not necessarily 
always present.

(c) the "<URL>" form in the current feature-hash draft was introduced for a 
potent reason:  to dispel any possible ambiguity concerning the order of 
substitution and hash value calculation.

I think there is a need to draw a clear distinction between simple-valued 
("primitive") features and composite-valued aggregates, else undesired 
complexities or even non-determinism may result.

However, I do believe there is value in providing a well-defined mapping to 
URI form, with URL and resolution available where appropriate.  I happen to 
like the idea of using a URN form, as suggested by Larry, as part of the 
solution.

Currently, I perceive there are a two fixed points to be accommodated if 
the range of proposed capabilities is to be realized:

    Feature tags (currently the basis of CONNEG expressions)
    URLs (currently the only proposed form of directly resolvable identifier)

As far as I can tell, you are proposing what is, in effect, a direct 
mapping from feature tag to URL:

    Tag --> URL

and a corresponding:

    Aggregate --> URL

I would suggest allowing an intermediate URN form that can represent the 
difference between primitive and aggregate values:

    Tag       --> URN:a:xxx
    Aggregate --> URN:b:xxx

The URNs here would use different URN namespaces, with different resolution 
properties.  As I suggest above, I'm not convinced that feature URNs should 
be further resolvable (for now, at least;  it's possible that we'll devise 
a useful machine-interpretable form for these in future).  OTOH, it will 
sometimes be useful for aggregate URNs to be resolvable, using ad-hoc or 
(to-be-)standardized URN resolution mechanisms, possibly on a 
per-application basis.  A possible ad-hoc mechanism might be a simple 
textual subsitution of the 'URN:namespace' prefix for an 
'http://host/path/' form of prefix;  for aggregate names that contain URLs, 
the resolution mechanism may be to simply dereference to URL.

In summary, if I understand your proposal correctly, I am proposing adding 
a level of indirection via URNs to allow evolution of a uniform resolution 
framework while preserving the essential distinctions between tags and 
aggregates.

I'm not yet sure how to address my point (c) above in this framework, but I 
suspect that admits a reasonable simple solution.  One approach would 
simply be to say that the hash is always calculated without further 
substitution, and that dereferenced expressions would not (normally) be 
permitted to contain further references.

I trust I've not grasped _completely_ the wrong end of your proposed.

#g
--


At 12:21 PM 12/20/99 -0800, [email protected] wrote:
>Over the past few months, the group has struggled with the question of
>how to reference aggregations of features; we have discussed most
>extensively proposals based on MD5 hashes and based on URIs.  During
>those discussions, it has been clear that there were different use
>cases for which different methods were more appropriate.  For very
>feature and resource rich environments, URIs have some clear
>advantages; for feature and resource limited environments, hashes have
>advantages.  The obvious solution, support both, has been proposed
>several times, but I have pushed back as chair to see if we can't come
>to resolution on a single system which works across multiple
>environments.  After discussion with the document authors and IANA,
>my current thought is this:
>
>Work with IANA to change the form of the feature registry so that
>registered features are directly referencable by individual URLs.  (The
>current registry format is a single text page containing all of the
>registered features).  This will allow us to reference registered
>(unfaceted), global, and unregistered features using URLs, which has
>not been possible up to this point.
>
>Use URLs as the pointers for feature aggregates.  As a special type of
>reference, allow an object identifier URI based on the MD5 hash of the
>canonical representation of the feature tag and value; the canonical
>representation for the feature tags will be the URL pointer to the tag
>(the value representation will continue to be set during
>registration).  The MD5 hash URI could either be a unique scheme,
>registered according to the recently established URI registration
>guidelines, or a data URI (possibly requiring a content type
>registration through the MIME processes).
>
>I believe that this approach gives us a reasonable implementation
>path for systems with a variety of resource constraints.
>
>Please consider this carefully in light of your intended use of
>the CONNEG systems, and send comments and criticism to the list.
>                         regards,
>                                 Ted Hardie

------------
Graham Klyne
([email protected])