Re: [whatwg] File package protocol and manifest support?
On Mon, 18 May 2009, Brett Zamir 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. This seems reasonable, but I think this is the wrong venue to peruse such a proposal. I recommend proposing this to the IETF. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] File package protocol and manifest support?
On Mon, May 18, 2009 at 5:41 AM, Brett Zamir bret...@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
[whatwg] File package protocol and manifest support?
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). Brett
