Re: Excess URI schemes considered harmful

At 03:05 AM 2001-09-26 , Roy T. Fielding wrote:
>
>Personally, though, I don't see any reason to standardize all IANA field
>values as some sort of URI or another.  A media type is simply an identifier
>within a given context, and the Content-Type field name is more than
>sufficient to establish that context.
>

AG::  Almost.  Content-Type is itself a name which is defined in the domain of
RFC-822-like headers.  For use outside that domain, Content-Type has to be
qualified.

At 01:52 AM 2001-09-26 , Harald Alvestrand wrote:
>
>being the heretic, as usual....

<grin/>

>...if you want something that names a media 
>type, why not use the standard syntax for naming media types, rather than 
>shoehorning it into an URI space?
>

AG:: Because the standard syntax is only safe (recognizable) the RFC-822
header
context.  The point of URIs is that they creates a single non-colliding space
for "references outside this context" which is not aware of what is a type,
what is an instance, or much of anything else.

In this case we _are_ trying to import a name from a specialized domain of
discourse, to refer to the sense of the name in a context other than the
context where the name was first used.  Sometimes it is useful for something
like this to be re-packaged for delivery into the context of use.  URI syntax
is useful as a multipurpose packaging so indications so packaged mix and match
very broadly and so the use contexts don't have to have lots of rules and
recognizer methods of their own.  We are not trying to take the text/plain
notion out of its home space.  But the RFC-822 syntax does not necessarily
armor the information payload adequately for recognition when taken out of
context.

The proposal is to match the model of the context of origin, not the
syntax. If
we use universal syntax this can reduce the transformation count to one or
two,
not N^2.

To match Roy's excellent observations on what the model is in the domain of
origin, one uses X.500 logic about nested domains of discourse and URN syntax,
as Michael has.

A useful semantic ancestor here is Dublin Core.  How do we identify an
utterance?  Because we identify a type by pointing to the agreed master
instance of an utterance where the [acceptor condition for the] type is
described.  If we map the model as a specialization of Dublin Core we start to
get somewhere.

What Rob wants is a normalized string representative usable in the context of
the SMIL player's dialog with its environment.  

Just getting it into URI form only guarantees to separate it from other URIs,
not to reduce the URI form to uniqueness per what you want to refer to.  This
is best addressed at the source.  If IETF/IANA will normalize the tokens to be
used for Dublin Core identification of its utterances, then the URN transform
is clear and clean.  The field name and value spellings are already given.  

If the original name givers don't agree to some nomenclature for themselves or
their utterances in a broadly re-usable context, it is much harder to do it
after the fact by consensus.

Note:  In Rob's application, we need the generality of URIs for reference
because while the type may be a registered Internet Media Type, it may not.
 It
may be thatDescribedBy a document description document written in RDDL.

The types you can ask about should not be limited to the well-known types, but
should include all typeReferences for which the question "do you have a
handler
for ..." is well posed.

The environment is going to search both for the named type and inferrable
supertypes as to what it has handlers for.  Select the best fit that copes. 
This is straight from the adaptation of device independent content for oddball
delivery contexts employed by people with disabilities.  Unpublished, but we
are working with DI on it.

So the space of types to be cited is published types, not registered types.
 We
need to be able to represent the registered types in this broader domain
without danger of confusion.

And what is easy should be easy.  So one should be able to expect
uniqueness in
the "published types" representation of registered types.  Not for all
published types, but for the registered ones, on has the degree of
centralization necessary to fix the normalization and stick with it.

Al

>....Roy
>

Received on Wednesday, 26 September 2001 08:47:27 UTC