- From: Chris Lilley <chris@w3.org>
- Date: Fri, 1 Oct 2004 13:24:44 +0200
- 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 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#rf-whiteSpace 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 >>rectangle? >> >>Cheers, >>-- >>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