On 9/1/06, Marcos Caceres <[EMAIL PROTECTED]> wrote:
Furthermore, our aim is to find the middle ground between what is currently out there, what the community wants, and the best technical solutions. Please note that the best technical solution might not be the easiest solution for developers and end-users, so we need to make compromises. Please see the design goals for the document [1]. Please note that the requirements document may imply solutions, but it does not explicitly give any (apart from using XML as the manifest format).
FWIW, I think it might be presumptuous to assume a manifest. I suppose it's likely given that manifests work well in situations where write-efficiency can be traded off for read-efficiency (such as this one), but they also have non-trivial drawbacks (e.g. more complicated for authors). Besides, I'd prefer we avoid doing design in the requirements document. I'd suggest we try to discover the requirements that may have motivated the use of a manifest. Can any implementors speak to that? Mark.
