W3C home > Mailing lists > Public > www-svg@w3.org > October 2004

Re: Spec question: whitespace in attributes

From: Chris Lilley <chris@w3.org>
Date: Fri, 1 Oct 2004 13:24:44 +0200
Message-ID: <1049790401.20041001132444@w3.org>
To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Cc: Ian Hickson <ian@hixie.ch>, www-svg@w3.org

On Thursday, September 30, 2004, 10:57:24 PM, Jon wrote:

JF> Ian,
JF> This is actually a tricky issue.

JF> If you read the most recent SVG Recommendation 
JF> (http://www.w3.org/TR/SVG11), then I could see how people could conclude
JF> that putting a space within an "x" attribute on a <rect> element would be
JF> an error. This conclusion would be based on the fact that the specification
JF> describes the grammar for a <length> by referring to the grammar for a
JF> <number> which is described in 
JF> (http://www.w3.org/TR/SVG11/types.html#DataTypeNumber) as consisting of
JF> things such as digits and periods and does not mention the possibility of a
JF> space.

Although the grammars for the more complex types do explicitly allow
leading and trailing whitespace.

JF> However, it seems to me that SVG should have been referencing XML Schema
JF> Datatypes (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/) for the
JF> definition of primitive data types which overlap with  XML Schema 
JF> Datatypes. For example, XML Schema Datatypes has a "decimal" primitive
JF> datatype which is an exact match for the SVG datatype, with the notable
JF> exception that XML Schema Datatypes seems to allow whitespace around
JF> primitive datatypes. (I'm not sure.)

It depends on the value of the whitespace facet in the schema

Basing (the types that overlap) on the schema datatypes would have the
additional advantage in nuDOM that the canonical form would be returned,
thus continuing the trend that scripters want the value of an attribute
not, in general, the precise lexical form in which it was expressed.
There is little value in preserving a difference betwen "   100 " and
"100" and "1E2" and "100.00000" if you already know the attribute is a float.

JF> So, I think this should be classified as an open issue and taken up by the
JF> SVG WG. For the time being, content creators are advised to not insert
JF> extraneous whitespace in their attribute values.

JF> (One reason SVG has its own definitions is that there isn't an exact match
JF> between SVG's data types and XML Schema Datatypes. Also, the datatypes
JF> parts of the SVG spec were written long before XML Schema Datatypes became
JF> a Recommendation, and then the SVG WG didn't remember to update that part
JF> of the SVG spec.)

There still isn't, because W3C XML schema decided not to add
concatenation as a means of type creation. Despite that fact that these
are widely used, including in XSL and SVG. So its not possible to
describe "3mm" and "number followed by one of this enumeration of unit
specifiers" instead its a subtype of "string".

RNG allows other type libraries to be added in addition to the W3C XML
Schema ones.

JF> Jon

JF> At 04:01 AM 9/30/2004, Ian Hickson wrote:

>>Am I correct in assuming that leading and trailing whitespace in
>>attributes in SVG should not be ignored and should in fact cause the
>>document to be in error?
>>e.g. Am I correct in saying that this test:
>>    http://www.hixie.ch/tests/adhoc/svg/error/015.xml
>>...should display a green rectangle and an "error" notification, not a red
>>Ian Hickson               U+1047E                )\._.,--....,'``.  fL
>>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Friday, 1 October 2004 11:24:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:03 UTC