- From: Chris Lilley <chris@w3.org>
- Date: Tue, 20 Dec 2005 13:22:56 +0100
- 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
xxx>>?
Please note the EBNF for <list of xxxx> and the prose thataccompanies
it.
xxx>> How should multiple commas in a row be parsed?
Please see the following line of the EBNF
comma-wsp:
(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
http://www.w3.org/TR/xslt#qname
which in turn links to
http://www.w3.org/TR/REC-xml-names/#NT-QName
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.
http://www.w3.org/TR/SVGMobile12/implnote.html#UnsupportedProps
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.
http://www.w3.org/TR/SVGMobile12/intro.html#TermUnsupportedValue
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
know.
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