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

Re: XBL media type?

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 7 Sep 2006 10:17:08 -0700
Message-Id: <07DA3C2A-61F8-4CF7-8E2D-8429B3F9D776@yahoo-inc.com>
Cc: "Mark Baker" <distobj@acm.org>, public-appformats@w3.org
To: Anne van Kesteren <annevk@opera.com>

Why is a WG debating issues that are general to the entire Web? Isn't  
this what we have the TAG for? Take your issue to them, and be done  
with it. If their answer isn't practical, knock some sense into their  

Having each WG figure this out for themselves is wasteful, and will  
lead to multiple solutions to a common problem.

On 2006/09/07, at 7:50 AM, Anne van Kesteren wrote:

> On Thu, 07 Sep 2006 16:11:14 +0200, Mark Baker <distobj@acm.org>  
> wrote:
>>> 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.
> I don't understand that "wait." Things are solely based on  
> namespace-dispatching not MIME dispatching.
>> 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.
> See above.
>> 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.
> If it's not necessary it will confuse people for ages. Which means  
> a lot of cost as they could be doing useful work instead of getting  
> confused about optional things.
>>> 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?
> If it's optional you have this issue anyway. It would be nice if  
> you made it more clear what you're proposing.
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

Mark Nottingham
Received on Thursday, 7 September 2006 17:17:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC