Pardon me for stepping in on this conversation in the middle, but it
has brought to mind a question about whether or not Atom should
support the ability to specify a hash value for resources linked to
using the link mechanism.  The link can be used, for instance, to
verify whether or not the resource being linked to has been modified
since the link was created.  This is particularly relevant to
enclosures which may be of arbitrary content type and involve the user
downloading bytes to their computers.  Perhaps we should add two new
attributes to the link element?

 <link rel="enclosure" href="http://example.com/somefile.mp3";
         hash="{generated_hash_value}" 
         hashalg="{uri_identifying_the_hash_algorithm_used" />

The hash and hashalg attributes would be optional but MUST appear together.

Thoughts? (If we have more than two people respond favorably to this,
I'll write up a Pace for it)


On Thu, 6 Jan 2005 14:04:04 +0100, Danny Ayers <[EMAIL PROTECTED]> wrote:
> 
> +1 it is then.
> 
> (with multiples, and including the aspect ratio/resize hint - that
> seems good pragmatism)
> 
> 
> On Wed, 05 Jan 2005 17:04:39 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
> > On Jan 5, 2005, at 4:25 PM, Danny Ayers wrote:
> >
> > > 1. If the media object is the primary content of the entry (which
> > > seems to be the main use case for RSS 2.0's <enclosure>), shouldn't it
> > > be delivered using some form of the <content> element?
> >
> > I used to think that, but we observe in the RSS2 world that there's a
> > well-accepted use case for something that's specially designated for
> > different handling.  Why fight it?
> >
> > > 2. Without multiple rel="enclosure", how does support and
> > > differentiate between media objects that are essentially the same
> > > resource but different formats, where the difference may not (easily)
> > > be expressed using mime types? Example:
> >
> > I'm pretty well convinced that multiples can't hurt.
> >
> > > 3. I don't think this Pace is the right place for listing what should
> > > go in the <link> registry - separation of concerns and all that
> >
> > That's because it's done as a delta to FieldingLinks, the new languages
> > goes in a couple of places in that section so I just preserved it.
> >
> > > 4. What do we call an inline (i.e. base64 encoded content) media
> > > object - an attachment?
> >
> > Nope, that's just <content>  -Tim
> >
> >
> 
> 
> --
> 
> http://dannyayers.com
> 
> 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]

Reply via email to