[rfc-i] Format for STDs, BCPs, FIYs

Julian Reschke julian.reschke at gmx.de
Thu Aug 16 07:59:55 PDT 2012


On 2012-08-16 16:45, Leonard Rosenthol wrote:
> On 8/16/12 10:41 AM, "julian.reschke at gmx.de" <julian.reschke at gmx.de> wrote:
>> What I want is a canonical URI that represents, for instance, the STD,
>> and gives usable information to a Web browser user.
>>
>> That implies either some kind of directory/summary page, or a compound
>> document.
>
> The former seems like a reasonable thing, though I would be concerned
> about the latter.  In both cases, I wonder if this is the type of thing
> that could/should be produced dynamically on the server side or would need
> to be pre-built?!?!

Generation should be automated, in which case it doesn't matter whether 
it's on-demand or whenever the STD/BCP/FIY changes.

>>> OR you want a set of documents that are actually collected together into
>>> a
>>> new document, which is what formats such as EPUB and PDF provide. That's
>>> not to say that you can't link to, into or out-of EPUB or PDF, of
>>> course.
>>
>> Can you demonstrate how to link *into* an epub using a browser? As far
>> as I understand, browsers do not support epub at all right now.
>
> The same way you can link into a PDF - the URI (or CFI in the case of
> EPUB) is passed along to the plugin/app that actually manages the EPUB
> format for the user.   Granted, this may not work in all cases on all
> platforms.  But that's an implementation problem not a standard/spec issue.

Understood :-). However, *right now*, most people don't have epub 
readers in their browsers.

In practice, an epub is just a set of HTML files + metadata; so the 
*only* benefit over a set of HTML files would be packaging. Does it 
matter for this use case?

Best regards, Julian



More information about the rfc-interest mailing list