Hampus Wessman wrote: > My suggestions would make the new format backwards incompatible, but > AFAIK the ID isn't completely compatible with most current > implementations anyway (not meta data at least). I think it is more > important to make the standard as good as possible than making it > backwards compatible. Clients with support for 3.0 will be able to add > support for the new standard easily anyway.
In theory, compatibility is already broken. The namespace URI was changed due to IETF request. In theory, changing the namespace is equivalent to renaming every tag, since tagname comparison should be done on the (namespaceURI, localName) pair. *This is a great opportunity to do breaking changes* > Change 1: Remove unnecessary tags that carry no information > > The metalink format contains some tags that could be removed without > losing ANY functionality. I'm thinking about <files>, <verification> and > <resources>. They may look pretty to humans, but I think the format > would be easier to deal with if they were removed. A metalink contains > one or more files, which contains hashes and urls (among other things). > The following xml structure reflects this hierarchy just as well as the > current one: > > <metalink> > <file name="example.ext"> > <identity>Example</identity> > <hash type="md5">2156346474343745</hash> > <url>http://example.com/</url> > <url>ftp://ftp.example.com/</url> > </file> > <file name="example2.ext"> > ... > </file> > </metalink> > > In my experience it would be easier to parse/load/read a metalink with > that structure. It may depend on how you do that, but I can't think of > any situation when it would make it harder. I agree. However, for implementation simplicity, I think we should still enforce some limits that are currently implicit due to the container tags. For example, all hashes being together and not interleaved with URLs, especially if they are piece hashes. > Change 2: remove "piece" attribute from piece hashes > > My suggestion: remove the "piece" attribute and require that the piece > hashes are placed in the correct order. Agree. And if decide not to remove the attribute, I think we should still say it MUST be in incremental order (for implementation simplicity). About 3 and 4: as I said in another post, I think it would be a good idea to get rid of all metadata tags in the metalink namespace, and reuse an existing metadata format like Dublin Core instead. http://dublincore.org/documents/dc-xml-guidelines/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
