Re: [SVGMobile12] 5.8.3: disallowed feature strings

David,
Good catch.

At 02:52 PM 5/3/2005, L. David Baron wrote:
>http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/struct.html#RequiredFeaturesAttribute
>says:
># Only feature strings defined in the Feature String appendix are
># allowed.

What that really means is that only the SVG spec is allowed to define 
feature strings. Other parties are not allowed to extend the SVG language 
via new feature strings; only the W3C. Other parties that want to extend 
the SVG language for specific workflows should use 'requiredExtensions' 
instead of 'requiredFeatures' and feature strings.


>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.)

If a particular feature string is not supported, then the 
'requiredFeatures' test attribute should return a false value, which causes 
the element with the test attribute to not render.

>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.

Yes, the above wording is confusing. Perhaps it should say "unsupported 
values other than unknown feature strings" or "(These rules do not apply to 
test attributes such as 'requiredFeatures'.)" or something like that.


>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.

Yes.

>  2. Either:
>     a. The appendix on feature strings [4] should define (probably by
>        reference) the feature strings defined in earlier versions of
>        SVG, or

Yes.

>     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.

If we do (a), I don't think we need to worry about (b) except to make clear 
how older version feature strings are equivalenced to SVG 1.2 feature strings.


>(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.)

We need to be clear enough so that at least you can understand the spec. :)

Jon


>-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

Received on Tuesday, 3 May 2005 22:08:34 UTC