W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

Re: [SVGMobile12] SVGT12-207: No conformance criteria for how to parse attribute values

From: Chris Lilley <chris@w3.org>
Date: Tue, 20 Dec 2005 13:22:56 +0100
Message-ID: <1155242651.20051220132256@w3.org>
To: Ian Hickson <ian@hixie.ch>
Cc: www-svg@w3.org

On Wednesday, December 14, 2005, 7:50:46 AM, Ian wrote:

IH> The Basic Data Types chapter (chapter 4) lacks UA conformance
IH> criteria. It states what the syntaxes are, but does not describe how
IH> to parse them. For example, what are the parsing rules for <list of

Please note the EBNF for <list of xxxx> and the prose thataccompanies

xxx>> How should multiple commas in a row be parsed?

Please see the following line of the EBNF

    (wsp+ comma? wsp*) | (comma wsp*)

IH> Similarly with
IH> <xslt-qnames>: What if the prefix used is not declared?

As defined in xslt1.0. Please follow the link in the spec to
which in turn links to
which says

  The namespace prefix, unless it is xml or xmlns, must have been
  declared in a namespace declaration attribute in either the start-tag
  of the element where the prefix is used or in an an ancestor element
  (i.e. an element in whose content the prefixed markup occurs).

IH> Where does it say that UAs must parse keywords case-sensitively?

XML is case sensitive by default. Specific deviations from that, to
accomodate and case-insensitivity mandated by other specifications, is
noted as required or comes from following the normative references.

IH>  (There are
IH> requirements on content authors in the Styling chapter, but I can't
IH> find any matching requirements for UAs.)

Attribute values that don't match the format are unsupported values, and
we do say what to do.


Known attributes with unsupported values are treated as if they hadn't
been specified when rendering.

unsupported value

  An unsupported value is a value that does not conform to this
  specification, but is not specifically listed as 'in error'. See the
  Implementation Notes for more detail on processing unsupported values.


IH> Please update the draft to give precise conformance criteria for user
IH> agents stating how each value is to be parsed, including covering
IH> details like how to handle leading and trailing whitespace, being
IH> explicit about what parse errors consist unsupported values (resulting
IH> in the attribute being ignored) and which parse errors should be
IH> handled in particular ways (without dropping the value), stating what
IH> the rules regarding case sensitivity are, and so forth.

As far as we can see,the EBNF covers that, together with the sections
quoted above. If you find a specific case that is not, please let us

IH> Note that there is currently a statement that the normative reference for
IH> syntax rules is the CSS2 specification, but this is clearly inaccurate, 
IH> since:

IH> * SVG 1.2 Tiny presumably doesn't use the
IH> @rule/selector/property:value syntax of CSS,

Right (we tried to say that in the previous draft, but you objected to
our saying that).

IH> * CSS2 values don't acces unitless lengths, which the SVG 1.2 Tiny
IH> syntax chapter says are the only allowed syntax for lengths,

The length in SVG is an SVG length. It clearly needs to refer to values
in a coordinate system, since SVG is scalable. Thus, its not a CSS
length. Nor does it claim to be.

It does discuss the two attributes that allow CSS units, true. Is that
the wording that leads you to assume an SVG length is intended to be a
CSS length? XSL also has units, so perhaps we should remove "CSS" from
in front of "units"?

IH>  * CSS2 properties and values are case-insensitive, but the SVG 1.2 
IH>    Tiny styling chapter says it is case-sensitive,

Yes, the XSL WG asked us (in the 1.0 timeframe) to make the properties
and values be case sensitive the same as XSL, after all it is XML.

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Tuesday, 20 December 2005 12:23:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:05 UTC