RE: [SVGMobile12] more on data types

Hi, Anne-

Thanks for your comment.

Anne van Kesteren wrote:
| 
| I created some simple testcases to check how attribute values 
| are actually
| parsed in current browsers:
|  <http://annevankesteren.nl/test/xml/svg/data-types/001.svg>
|  <http://annevankesteren.nl/test/xml/svg/data-types/002.svg>
| 
| The first tests case-sensitive matching. In theory the 
| testcase square should be "black" (the initial value),
| but in Opera, Mozilla and Internet Explorer with
| the Adobe plugin it is "RED". The same is true for the second 
| testcase, all three render the value " red" as "red".

We truly appreciate your diligence in creating test cases and reporting the
results. This helps us make sure that the specification is as solid as it
can be.


| Given that CSS allows case-insensitive matching I'm not sure 
| how you could use the parser for these color values. 

Yes, CSS has a different behavior here than SVG. SVG follows the stricter
parsing rules of XML. Thus, the lexical space for properties is different
when properties are defined in presentation attributes as opposed to author
style sheets (be they external, style elements, or style attributes). Note
that Tiny does not allow any of those three forms of author style sheet, so
it doesn't apply here, but this is the case for Full.


| For CSS values it is also doesn't really matter if  
| they are preceded by a space.

Leading and trailing spaces are explicitly disallowed by SVG Tiny 1.2 except
where specifically noted, and a UA that allows them is non-conforming. We
feel that the complications involved in changing this would outweigh any
possible benefits. In certain cases, we do allow them (in particular, for
certain complex microsyntaces), and that will be reflected in the EBNF. 


| I'm wondering if the SVG WG could describe error handling 
| that more closely matches what is actually implemented
| as what is implemented is probably also used. 

This is a reasonable stance, but unfortunately, there are other
considerations. The SVG WG is following the generic behavior of XML, and the
request of the XSL group in ensuring that case sensitivity is preserved.
This is not only to help with interoperability with the family of XML
technologies, but also to ensure strict interoperability between conforming
SVG implementations.


| Also, are things like:
| 
| # style="FiLL:ReD"
| 
| ... allowed? In other words, should inside the "style" 
| attribute and <svg:style> elements normal CSS rules apply?

Neither style attributes nor style elements are not allowed in SVG Tiny, so
again this is only an issue for Full. In any case, SVG does not dictate the
behavior of the CSS lexical space, which includes the lexical values of the
style attribute and element.

It should be noted, though, that the value space of this attribute value
should be the same as that of SVG, even if the lexical space is different.
This is our aim.


| It should at least become more clear how to _exactly_ parse 
| such attribute values. (This is different from describing how 
| they can be used.) Currently that is not entirely clear to me. 

Attribute values should be parsed exactly according to the definition and
their data type. If the type has EBNF rules, or externally referenced
definitions, those should be followed. If not, then the string literal
values, with no leading or trailing spaces, with case-sensitivity, are the
only options for supported values. This is intended to preserve
interoperability between implementations (viewers, authoring tools, et al)
and between SVG and other XML languages. 

We believe that this is suffiently clear to implementors who interpret the
specification literally, rather than reverse-engineer other implementations.


If this does not satisfy your concern, please respond within 2 weeks with
further clarification.

Thanks-
Doug, on behalf of the SVG WG

Received on Tuesday, 27 June 2006 16:09:38 UTC