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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
