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: Ian Hickson <ian@hixie.ch>
Date: Wed, 21 Dec 2005 21:15:37 +0000 (UTC)
To: Chris Lilley <chris@w3.org>
Cc: www-svg@w3.org
Message-ID: <Pine.LNX.4.62.0512212104430.17886@dhalsim.dreamhost.com>

On Tue, 20 Dec 2005, Chris Lilley wrote:
>
> 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
> IH> xxx>>?
> 
> Please note the EBNF for <list of xxxx> and the prose thataccompanies 
> it.

EBNF doesn't describe parsing rules, just a syntax.

Given "2 2 2 2", there does not appear to be anywhere in the SVG spec that 
specifically says that this should be treated as a four-item list with 
four integers. I can tell that it is syntactically correct or not in 
certain cases, but not how to actually handle it once I know that. (The 
spec does imply certain likely interpretations, but it is not explicit.)

Please be explicit about how UAs must interpret attribute values.


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

This says that multiple commas don't match the grammar, it doesn't say how 
to handle them if they are there. (However, if it is the intention, as 
noted below, that rendering UAs should include conformance checkers, then 
I accept that the processing of multiple commas is defined.)


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

Those are document author requirements, not user agent requirements. 
Again, though, this may be ok, as noted below.


> IH> Where does it say that UAs must parse keywords case-sensitively?
> 
> XML is case sensitive by default.

Attribute values are not part of the XML syntax; XML makes no requirement 
on the case-sensitivity of attribute values.

Please explicitly state that user agents must compare values in a 
case-sensitive manner rather than a case-insensitive one.


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

So to summarise, rendering user agents must include conformance checkers?


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

No, my confusion stems from the fact that SVG claims to use the 
'font-size' property -- which is defined in CSS and XSL as taking values 
that accept units -- and claims to use CSS' syntax rules -- which again, 
accept units -- while simultaneously stating that lengths in SVG do not 
accept units.

I don't mind if they do or don't accept units. I would just like it to be 
clearly defined so that as a user agent implementor I know whether to use 
the CSS syntax rules (which accept units, are case-insensitive, etc) or 
some other, as yet undefined, SVG-specific syntax rules.


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

My three points were not meant to be criticism. I was merely pointing out 
that the existence of those three points results in an intrinsic 
contradiction in the aforementioned statement to the effect that SVG uses 
CSS's syntax rules.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 21 December 2005 21:15:53 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT