OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)

On Wed, Sep 3, 2008 at 9:22 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Anthony Bryan wrote:
>>> So, in general, this would be for IRIs that do not identify a resource to
>>> download, but metadata about a resource to download? Strictly speaking,
>>> isn't metalink not yet another format for that?
>> Yes, it is.
>> Do you think about a "metadata" element (a sub-element of
>> "resources")with a required "type" attribute of MIME type is
>> appropriately generic?
> Sounds good.
>> This could then be used to describe Metalinks if needed, and other
>> types that may come later.
> Right.
>> I don't think BitTorrent's MIME type is in the is listed in the IANA
>> MIME Media Types. Would this be a problem?
>>   <?xml version="1.0" encoding="UTF-8"?>
>>   <metalink xmlns="http://www.metalinker.org";>
>>     <files>
>>       <file name="example.ext">
>>         <resources>
>>           <url>ftp://ftp.example.com/example.ext</url>
>>           <url>http://example.com/example.ext</url>
>>           <metadata
>> type="application/x-bittorrent">http://example.com/example.ext.torrent
>>           </metadata>
>>         </resources>
>>       </file>
>>     </files>
>>   </metalink>
> One of these issues that regularly come up :-)
> One way out of that would by to "grab" special type names like "torrent",
> and hardwire them. That should be ok as long as they can't collide with
> registered names (thus no "/" allowed).

Great, thanks Julian! Thanks to the other people that mentioned this
as well, it seems much cleaner & tightened up now. :)

Do I need to explicitly state no "/" allowed, or just know any that
ones I'm defining can't be "/" ?
And would it be better to just allow the unofficial MIME type, instead
of essentially creating an unofficial registry with one or a handful
of entries? Or is MIME types plus hardwired entries better?

Here is the changed text:

4.2.9.  The "metalink:metadata" Element

   The "metalink:metadata" element contains the IRI of metadata about a
   resource to download.  For example, this could be the IRI of a
   BitTorrent .torrent file or a Metalink Document.

   metalinkMetadata =
      element metalink:metadata {
         attribute preference { xsd:integer }?,
         attribute type { metalinkTextConstruct },
      }+  The "preference" Attribute

   metalink:metadata elements MAY have a preference attribute, whose
   value MUST be a number from 1 to 100 for priority, with 100 used
   first and 1 used last.  See the "preference" attribute of the
   metalink:url element for more information.  The "type" Attribute

   metalink:metadata elements MUST have a "type" attribute that
   indicates the MIME type of the metadata available at the IRI.  In the
   case of BitTorrent as specified in [BITTORRENT], the value "torrent"
   is required.

   Metalink Processors that do not support a specified type of metadata
   about a resource to download MUST ignore that metadata

4.2.18.  The "metalink:url" Element

   The "metalink:url" element contains the IRI of a file.  All IRIs MUST
   lead to identical files.

(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS