Re: Oops...

[Andrew Pam <xanni@xxxxxxxxxxxxxxxxx>]

On Tue, Apr 21, 1998 at 03:26:40PM -0700, Thom Phillabaum wrote:
> > I was thinking of something like a "|bytes(x-y)" fragment identifier
> > where X is the starting byte (integer >= 0) and y is the ending byte
> > (integer >= x).  Omitting x would imply the start of the resource and
> > omitting y would imply the end of the resource.  Clearly it makes no
> > sense to omit both.  :-)  If the server doesn't support the "Byte Range"
> > header and you get the entire resource back, Mozilla should still be
> > able to discard the unwanted parts.
> >
> > The vertical bar connector "|" is defined to be interpreted by either
> > the client or server, as opposed to the hash mark connector "#" which
> > is supposed to be interpreted only by the client.  We should therefore
> > also add support for this notation to web servers so that links will
> > still work on browsers that don't (yet) support this extension.
> >
> > Also, <OBJECT> needs to be able to display "text/*" MIME-types inline
> > rather than having to put them in a frame like <IFRAME>.
>
> Two issues come to mind. First, I'm not sure how the browser would be able to
> tell if the server supported the "bytes" construct or not. It just gets the
> data back from the server and didn't know beforehand how big the resulting
> data was so I can't see how to reliably determine it from the browser-side
> (especially with the (x-"end-of-document") case where you wouldn't know how
> many bytes you're requesting).

Are you sure?  I thought most servers sent a MIME "Content-Length" header
in many cases.  Anyway, once the data has come back, we can check if it
matches the expected number of bytes except in the case where the end
position of the request is not specified.

> Plus the "browser needs to interpret part of the URL" approach is less than
> clean and I can't think of anything that currently works that way. I'm not
> saying it's not possible or a bad solution, but I am saying you might want to
> think about it some more and maybe come up with a different mechanism.

But that's exactly how the existing "#id" fragment identifiers already work,
have always worked, and how the W3C fragment-identifier specifications say
it should work, as far as I can tell.

> Second, I think using a byte indices is problematic. I can imagine a
> situation where the length of a document might change each time the server
> sends it out. For instance, the server might stamp it with the date so
> sometimes you'd get a one digit date and other times two digits. There are
> other cases like this as well (for example a page with a hit counter).

That's true, and this mechanism wouldn't really be useful for dynamically
generated content.  However, the majority of the content on the web is
still static content; also, this mechanism is fully general across all
one-dimensional media types such as audio and video as well, another
major application.

> While it would limit your flexibility, you might want to look at XML. Then
> you could use structured tags as your quoting markers.

That is already in the W3C XML-pointer specifications, so I don't need to ask
for it!  My point is that it's not sufficient, because sometimes we want to
be able to transclude unstructured data too.  There's plenty of content on
the web that is not in XML, and it's no solution to say that authors must
convert all existing content to XML in order to use these features.

> I know (well, I think I know) this is counter to Xanadu's idea of quoting,
> but simply referring to a byte range I think is going to be the source of a
> lot of breakage.

Possibly, but that depends on the circumstances, and just because it
won't solve all problems doesn't mean that it wouldn't be useful under
some circumstances.  After all, I could make exactly the same criticism
about the <A HREF> links in the web today - they are the source of a
lot of breakage too, and if only you had all listened to us in the first
place, yada yada yada... :-)

Share and enjoy,
		*** Xanni ***
-- 
mailto:xanni@xxxxxxxxxx                         Andrew Pam
http://www.xanadu.net/xanadu/                   Technical VP, Xanadu
http://www.glasswings.com.au/                   Technical Editor, Glass Wings
http://www.sericyb.com.au/sc/                   Manager, Serious Cybernetics
P.O. Box 26, East Melbourne VIC 8002 Australia  Phone +61 3 96511511