W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2015

Re: Packaging Review

From: Liam R E Quin <liam@w3.org>
Date: Wed, 11 Feb 2015 18:37:15 -0500
To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
Cc: "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>
Message-ID: <20150211183715.4fc65776.liam@w3.org>
On Wed, 11 Feb 2015 09:24:45 -0500
"Siegman, Tzviya - Hoboken" <tsiegman@wiley.com> wrote:

> Thanks, Liam
> Perhaps I'm misunderstanding something, but I think it is possible to fetch individual items using the type parameter in the URL? 

> http://example.org/downloads/spending.pack#rel=describedby;type=application/ld+json
> is the example 15 the section on Fragment IDs [1]. This is a URL pointing the metadata in JSON-LD (as opposed the metadata in Turtle.

(note, frangment identifiers are not normally sent to Web servers, so you'd actually be sending 

What you get back from the server is a different resource in response.

If individual parts are binary, though, at least it's possible to build a table of byte offsets locally.

To answer Ivan's question, it's actually a little tricky to include a table of byte offsets in the package format at the start, because the size of that table would be included in any HTTP range requests. But not impossible. It needs to be part of the format, though, as otherwise intermediate software would be free e.g. to rearrange the order in which parts were delivered, as that's not significant in the format, but that would break any table of contents.

> In our publications world, might we see something like this to access the video element:
> http://example.org/downloads/bookTitle.pack#rel=describedby;type=
> video/mp4 

That doesn't work to get the thirtieth video element in the package.

You can give it an id and use that, but then where do you get the id from?

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Received on Wednesday, 11 February 2015 23:37:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:55 UTC