- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 8 Sep 2006 09:17:41 -0400
- To: Mark Baker <distobj@acm.org>, Anne van Kesteren <annevk@opera.com>, ext Mark Nottingham <mnot@yahoo-inc.com>
- Cc: public-appformats@w3.org
MarkN, MarkBa, MarkBi, Anne, Henri, Björn, All, Thanks for the interesting discussion on this issue. I have followed MarkN's suggestion and sent an e-mail to the www-tag mail list: <http://lists.w3.org/Archives/Public/www-tag/2006Sep/0059.html> I would appreciate it if all follow-ups on this subject be done on the above list. And please except my advanced apologies if that requires you to resend your previous comments on this subject. Regards, Art Barstow --- On Sep 7, 2006, at 1:17 PM, ext Mark Nottingham wrote: > > 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 heads. > > 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 > mnot@yahoo-inc.com > > > >
Received on Friday, 8 September 2006 13:19:17 UTC