RE: [SVGMobile12] more on data types

Hi, Anne-

Anne van Kesteren wrote:
| 
| 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.

I misspoke when I referred to the parser; I should have referred to string
matching. As far as case-sensitivity in XML, it's a matter of
interpretation. True, the XML Spec never explicitly says it is
case-sensitive for values, but it does imply it.

>From the Spec:
* XML processors SHOULD match character encoding names in a case-insensitive
way and SHOULD either interpret an IANA-registered name as the encoding
registered at IANA for that name or treat it as unknown

[DS: this implies that other values *are* case-sensitive]

* "string" matches a literal string matching that given inside the double
quotes. 

* 'string' matches a literal string matching that given inside the single
quotes.

* match [Definition: (Of strings or names:) Two strings or names being
compared MUST be identical. Characters with multiple possible
representations in ISO/IEC 10646 (e.g. characters with both precomposed and
base+diacritic forms) match only if they have the same representation in
both strings. No case folding is performed. (Of strings and rules in the
grammar:) A string matches a grammatical production if it belongs to the
language generated by that production. (Of content and content models:) An
element matches its declaration when it conforms in the fashion described in
the constraint [VC: Element Valid].]

[DS: Since case-folding is not performed, then it is up to the XML dialect
to define how permissive it is. SVG 1.1 did not sufficiently make this
distinction, though it is important in the case of path syntax. SVG 1.2
defines a strict subset of those attribute values, indicating that they must
be case-sensitive.] 


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

I prefer to say that my former statement was subject to interpretation and
specification, which we have done. 

In any case (no pun intended), the strict string matching is unquestionably
defined in XML, so this point is not open to interpretation.


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

The complications arise in ensuring that every technology we are attempting
compatibility with might allow leading and trailing spaces, not with
processing the spaces themselves. We prefer to use that strict subset of
lexical values known to work across multiple languages with no special
processing.


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

Right, we explicitly allow it there.


| > | 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! ;-)

Agreed. We underspecified it before, and implementations thus had different
behavior. We are correcting that now, and conforming viewers will reflect
that interoperability.


| > | 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's not that simple. There are other languages and tools to attempt
compatibility with, so a conservative approach to supported values converges
with more specifications than a liberal one.


| > | 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#D
| ataTypeColor  
| points to  
| http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/painting.htm
| l#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...

It does look like this case is problematic. I will recommend that we remove
the normative reference to HTML, or at the very least subset it to mandate
case-sensitivity (if that is allowed). The names of 16 colors are not
important enough to disrupt internal and external consistency.


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

You do if you are using SVG Tiny 1.2, because if you don't, it won't work.
;)

Seriously, the relative ease of authoring is a matter of personal opinion.
I'm not aware of any study done on this subject. Personally, I find
TitleCasing intuitive, so that name would present no problem to me.
Intuitiveness is subjective, so it's best not to assume that everyone feels
the same way, and instead rely on the definition in a specification. 

I hope that this will alleviate your concern.


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

No, but that is one source of such confusion, so I wanted to clarify what
the correct behavior should be. SVG Tiny is clear on the case of case (even
if this sentence isn't so clear). 


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

We will note your disagreement, but we do feel that we are doing the right
thing in being specific on these issues, since it will promote a more robust
workflow and interoperability among Web technologies.


Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Tuesday, 27 June 2006 21:23:59 UTC