SVG 1.2 Comment: XML Binding Language for SVG

3.3.1:

I'm not sure what "This specification only defines sXBL processing rules or 
stand-alone SVG documents" means.  Should that "or" be a "for"?

This specification should define error-handling for cases it does not cover (eg. 
when the bound element is not in a stand-along SVG document or the binding 
definition is not in a stand-alone SVG document).  Otherwise future expansion of 
sXBL capabilities is likely to run into non-interoperable handling of what SVG 
1.2 UAs would consider error cases.

3.3.2:

Again, the error handling behavior for the case when sXBL is applied to SVG 
elements should be defined.  If it's defined elsewhere in the specification, the 
"in error" text should link to said definition.

Henceforth, any comments requesting that the error handling be defined imply 
that it's acceptable to link to the error handling if it's defined elsewhere.

3.4:

"SXBL" (note capital 'S') seems to be a typo.

3.5:

The error handling when there is more than one child element in the 
xblChildNodes and the custom element is the target of a URI reference needs to 
be defined.

The error handling when a resource not in the given list is defined using sXBL 
custom elements needs to be defined.

3.6:

The error handling for the case when xblChildNodes don't satisfy the described 
criteria (are not all of the same type, are not all vector effect primitives, 
etc, etc) needs to be defined.

The error handling for the case when the animation elements in the xblChildNodes 
include an xlink:href attribute needs to be defined.

3.11:

The error handling for the case when style elements or xml-stylesheet processing 
instructions are included in the shadow tree needs to be defined.

3.12:

Should the "DOM interfaces for custom elements" part be its own subsection?

3.13:

The error handling behavior for the situations described in this section needs 
to be defined.

-Boris

Received on Tuesday, 23 November 2004 06:18:23 UTC