Re: [SVGMobile12] more on data types

On Tue, 27 Jun 2006 18:09:28 +0200, Doug Schepers  
<doug.schepers@vectoreal.com> wrote:
> | 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.

XML only has case-sensitive matching for attribute and element names. This  
is irrelevant to XML parsers.


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

Given that your former statement was incorrect, you might want to revisit  
this one. On the other hand, I guess this is correct since you don't want  
to have things like

  fill="/* */red"

and such...


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

How is leading and trailing space complicated?


> In certain cases, we do allow them (in particular, for
> certain complex microsyntaces), and that will be reflected in the EBNF.

Yeah, like for viewBox="".


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

Given the results of the tests, you're certainly doing the right thing! ;-)


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

Shouldn't you try to converge with the CSS WG on this?


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

Ok, so  
http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/types.html#DataTypeColor  
points to  
http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/painting.html#colorSyntax  
which points me to the HTML 4 specification (without giving a reference)  
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.5 which  
gives values such as "Red", "Silver" etc. and explicitly says they are  
case-insensitive. Apparently this is contrary to what the SVG WG actually  
wants...


Also for things like ThreeDDarkShadow you really don't want to remember  
the exact casing...


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

Did I ever say anything about reverse-engineering? And as pointed out,  
it's not really clear what is intended.


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

There you go.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 27 June 2006 16:33:55 UTC