sXBL: Extensibility and Versioning

Dear Scalable Vector Graphics Working Group,

  it seems the latest sXBL Working Draft does not discuss extensibility
or versioning of the format. It seems reasonable to expect that

[...]
  The intent is that, in the future, a general-purpose and modularly-
  defined XBL specification will be developed which will replace this
  specification and will define additional features that are necessary
  to support scenarios beyond SVG, such as integration into web browsers
  that support CSS.
[...]

the specification that replaces sXBL makes changes to the language that
would cause sXBL fragments to behave in unexpected ways or fail in old
processors that expect such fragments to be sXBL fragments. In order to
prevent such failure $whatever-comes-next would need to have features
that are recognized by old processors that properly communicate that it
is not "compatible" with such processors. As the document is considered
"nearly ready for Last Call" it would seem that the lack of such
functionality means one of

  * no partial understanding of "XBL", $whatever-comes-next gets a new
    namespace so processors would not confuse it with sXBL

  * embedding sXBL in SVG 1.2 always means that the "XBL" code is sXBL
    and using new "XBL" versions in SVG would require to use SVG > 1.2

  * downlevel-client compatibility is ignored, it breaks if it breaks

Please make it clear in the document which approach is taken here and/or
include proper functionality to handle the relevant issues. I (probably)
do not think that this is something to deal with in the SVG 1.2
specification as the fragment might not even be "in error" in such
cases.

regards.

Received on Friday, 22 October 2004 20:40:30 UTC