[SVGMobile12] 5.8.3: disallowed feature strings

http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/struct.html#RequiredFeaturesAttribute
says:
# Only feature strings defined in the Feature String appendix are
# allowed.

This does not say how user agents should behave when other feature
strings occur in documents.  (That is, it defines handling of known but
unsupported features but does not define handling of unknown features.)
This omission seems to imply that the relevant rules are the error
handling rules in [1] (thanks to the definition of unsupported values
in [2]):
# For known elements in the SVG namespace, unknown attributes that have
# no namespace and known attributes with unsupported values are treated
# as if they hadn't been specified when rendering. Unsupported values
# are defined in the definitions section. Unsupported values for known
# attributes must also cause a highly perceivable warning in the user
# agent.

This poses a number of problems:
 1. It is bad for forward compatibility, since a document that has a
    requiredFeatures value from SVG 1.2 Full that hasn't yet been
    invented, or a requiredFeatures value from a future version of SVG
    (whose processing seems permitted per [3]) would have the *entire*
    requiredFeatures attribute ignored, which would cause the element to
    be displayed when it otherwise should not be.
 2. It is bad for backward compatibility, since the feature strings from
    SVG 1.1 are not permitted values, and the processing of old
    documents under SVG 1.2 rules likewise seems to be allowed by [3].
    Therefore a conformant implementation would have to ignore the
    attribute in that case as well.

I believe two corrections to the specification are required:
 1. The sentence at the beginning of this message should instead say
    that unknown feature strings cause the requiredFeatures attribute's
    implicit return value to be false.
 2. Either:
    a. The appendix on feature strings [4] should define (probably by
       reference) the feature strings defined in earlier versions of
       SVG, or
    b. The rules on version control [3] should be clarified so that an
       SVG 1.2 implementation must not process an SVG document of a
       different version according to the rules in the SVG 1.2
       specification rather than the rules in that version's
       specification.

(I may be misunderstanding the versioning strategy used by SVG, so it's
possible that this suggestion may not make sense.  However, if that's
the case, the versioning strategy should be presented more clearly in
the specification.)

-David

[1] http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/implnote.html#UnsupportedProps
[2] http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/intro.html#TermUnsupportedValue
[3] http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/implnote.html#VersionControl
[4] http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/feature.html

-- 
L. David Baron                                <URL: http://dbaron.org/ >
          Technical Lead, Layout & CSS, The Mozilla Foundation