Re: Why sXBL first and then XBL 2.0?

* Robin Berjon wrote:
>>>* As a veteran of many W3C activities, I agree wholeheartedly that it is 
>>>indeed usually better to define a minimal version that addresses a 
>>>well-known set of needs first, and then learn from that, versus taking 
>>>guesses about how to solve all potential problems at once.
>> 
>> You mean you do not think that it should be a requirement for whatever
>> comes after sXBL that it is fully "backwards-compatible" with sXBL?
>
>Whoa, you're taking a huge leap full of unfounded assumptions here.

I am rather asking for clarification so I don't have to assume anything.
If a general purpose XBL language ought to be compatible to sXBL, it is
constrained in a number of ways, changing core concepts of the language
would be difficult or not feasible; that constrains how one could learn
from the sXBL approach and an evaluation for fitness of such a require-
ment would mean to take guesses how to solve potential problems. As Jon
states that it is usually better not to do that, I see the above a fair
interpretation but other interpretations are possible too, which is why
I ask. I would be surprised by his statement along with statements that
a general purpose XBL language MUST by fully compatible to sXBL, rather
than, for example, that compatibility would be nice - but not essential.