W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] File package protocol and manifest support?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 19 May 2009 23:16:43 -0500
Message-ID: <dd0fbad0905192116l939dfd5o375b242256342608@mail.gmail.com>
On Mon, May 18, 2009 at 5:41 AM, Brett Zamir <brettz9 at yahoo.com> wrote:
> While this may be too far in the game to bring up, I'd very much be
> interested (and think others would be too) to have a standard means of
> representing not only individual files, but also groups of files on the web.
>
> One application of this would be for a web user to be able to do the
> following (taking advantage of both offline applications and related
> somewhat to custom protocols):
>
> 1) Click a link in a particular protocol containing a list of files or
> leading to a manifest file which contains a list of files. Very importantly,
> the files would NOT need to be from the same site.
> 2) If the files have not been downloaded already, the browser accesses the
> files (possibly first decompressing them) to store for offline use.
> 3) If the files were XML/XHTML, take advantage of any attached XSL, XQuery,
> or CSS in reassembling them.
> 4) If the files were SQL, reassemble them in a table-agnostic manner--e.g.,
> allow the user to choose which columns to view and in which order and how
> many records at a time (including allowing a single-record "flashcard"-like
> view), also allowing for automated generation of certain columns using
> JavaScript.
> 5) If the files included templates, use these for the display and populate
> for the user to view.
> 6) Bring the user to a particular view of the pages, starting for example,
> at a particular paragraph indicated by the link or manifest file, highlight
> the document or a portion of the targeted page with a certain font and
> color, etc.
>
> It seems limiting that while we can reference individual sites' data at best
> targeting an existing anchor or predefined customizability, we do not have
> any built-in way to bookmark and share views of that data over the web.
>
> In considering building a Firefox extension to try this as a proof of
> concept, METS (http://www.loc.gov/standards/mets/ ) seems to have many
> aspects which could be useful as a base in such a standard, including the
> useful potential of enabling links to be described for files which may not
> exist as hyperlinks within the files--i.e., XLink linkbases).
>
> Besides this offline packages use, such a language might work just as well
> to build a standard for hierarchical sitemaps, linkbases, or Gopher 2.0 (and
> not being limited to its usual web view, equivalent of "icon view" on the
> desktop, but conceivably allowing "column browser" or tree views for
> hierarchical data ranging from interlinked genealogies to directories along
> the lines of http://www.dmoz.org/ or http://dir.yahoo.com ), including for
> representing files on one's own local system yet leading to other sites. The
> same manifest files might be browseable directly (e.g., Gopher-mode), being
> targeted to continguously lead to other such manifest file views until
> reaching a document (the Gopher-view could optionally remain in sight as the
> end document loaded), or, as mentioned above, as a cached and integrated
> offline application (especially where compressed files and SQL were
> involved).

Developing a Firefox extension is a sure way to strengthen your case.
It will help expose the real requirements, and highlight weaknesses in
the proposal.  Actual users will show you what parts are popular and
which aren't, which can direct one's efforts in adding things to the
spec.

~TJ
Received on Tuesday, 19 May 2009 21:16:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC