W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: XBL media type?

From: Mark Baker <distobj@acm.org>
Date: Thu, 7 Sep 2006 10:11:14 -0400
Message-ID: <c70bc85d0609070711q66a743efpe71f1815d67262fc@mail.gmail.com>
To: "Anne van Kesteren" <annevk@opera.com>
Cc: public-appformats@w3.org

On 9/7/06, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 06 Sep 2006 18:29:35 +0200, Mark Baker <distobj@acm.org> wrote:
> >> I don't really see what you mean with the efficiency argument
> >
> > I mean that I want to be able to hand off the incoming data stream to
> > the correct processor at the earliest possible time to minimize
> > latency, and since the media type arrives before the root namespace -
> > and in plain text form (not encrypted or compressed) - it's more
> > efficient to do so using its value.
>
> Since it has to go through an XML parser regardless (at which point you
> can easily make that check) I don't see the point.

Right, the parser doesn't matter.  But in the application/xml case,
there is a wait time between when the value of the Content-Type header
is received and when the processing of the data stream begins.  You
can't get that time back.  And there is no wait with
application/xbl+xml.

Given that XBL will largely be used for user-facing content, that
means a longer wait for users.  It's probably not much in a
high-bandwidth desktop scenario, but in a mobile context where both
processing speed and bandwidth is (relatively) low, it could be
noticeable.  More importantly, it's unnecessary.

Moreover, the cost of using a specific media type is, AFAICT,
completely in the registration process, which is a one-time (if all
goes well 8-) fixed cost.

> This isn't really an issue for XBL. The format expected when it's
> retrieved is XBL and if it's not it will simply yield in an error.

Which severely limits evolvability.  Are you sure there won't ever be
a competitor to XBL that the industry might want to migrate to?

See;

http://www.w3.org/2001/tag/doc/mime-respect.html#external

Mark.
Received on Thursday, 7 September 2006 14:11:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:20 GMT