W3C home > Mailing lists > Public > www-svg@w3.org > March 2008

SVG 1.1 XSD Comments

From: Gavin Kistner <!@phrogz.net>
Date: Wed, 19 Mar 2008 23:40:36 -0600
Message-Id: <B653210E-54C4-4DA8-A72A-9F13DB6B41A6@phrogz.net>
To: www-svg@w3.org

Using oXygen[1], I ran into the following problems with the SVG 1.1  
XML Schema:


1 - None of the three XSD files supplied by W3C (SVG.xsd, xlink.xsd,  
xml.xsd) would validate by themselves due to the DTD at the top  
specifying a SYSTEM DTD not present or available. I deleted these DTDs  
to move forward.


2 - In xlink.xsd, oXygen claims that the use of a 'use' attribute on  
<attribute> elements is not valid:

SystemID: /Users/phrogz/Downloads/xlink.xsd
Location: 39:37
Description: s4s-att-not-allowed: Attribute 'use' cannot appear in  
element 'attribute'.

This makes sense, I think. You may declare the optional/required/ 
forbidden nature of an attribute when it is used inside a complexType  
on a per-type/element basis, but not when it is being globally declared.

I deleted all the use="..." in xlink.xsd to move forward.


The remainder of the errors are against svg.xsd; all line numbers  
refer to the file after removing the DTD and offending content.


3 - In <attributeGroup name="stdAttrs">, this line:
	<attribute ref="xml:base" type="anyURI" use="optional"/>
produces the error:
	SystemID: /Users/phrogz/Downloads/SVG.xsd
	Location: 336:31
	Description: s4s-att-not-allowed: Attribute 'type' cannot appear in  
element 'attribute'.

This makes sense: you are referencing another attribute (with its own  
implicit type), and so the presence of a type attribute is conflicting  
and unneeded. I deleted this attribute to move forward.


4 - Similarly in <attributeGroup name="animElementAttrs">, this line:
	<attribute ref="xlink:href" type="anyURI" use="optional"/>
produces the error:
	SystemID: /Users/phrogz/Downloads/SVG.xsd
	Location: 837:33
	Description: s4s-att-not-allowed: Attribute 'type' cannot appear in  
element 'attribute'.

Again, deleting the attribute fixes the problem with no loss of  
information.


5 - This line:
	<attribute name="preserveAspectRatio"  
type="svg:PreserveAspectRatioSpecType" default="xMidYMid meet"/>
produces the error:
	SystemID: /Users/phrogz/Downloads/SVG.xsd
	Location: 1100:107
	Description: cvc-pattern-valid: Value 'xMidYMid meet' is not facet- 
valid with respect to pattern '(\s*("none"| 
x("Min"|"Mid"|"Max")y("Min"|"Mid"|"Max"))\s+("meet"|"slice")?\s*)' for  
type 'PreserveAspectRatioSpecType'.
URL: http://www.w3.org/TR/xmlschema-2/#cvc-pattern-valid

The pattern is broken in two ways. First, it is case sensitive, hence  
the capital Y in the default value would not match. Further, the  
copious presence of double-quotes in the original pattern makes no  
sense. As the 1.1 spec calls for a capital Y, the pattern should be:
\s*none|x(Min|Mid|Max)Y(Min|Mid|Max)(\s+(meet|slice))?\s*

This changes line 258 in <simpleType  
name="PreserveAspectRatioSpecType"> to:
	<pattern value="\s*none|x(Min|Mid|Max)Y(Min|Mid|Max)(\s+(meet|slice))? 
\s*"/>

6 - This line:
	<group ref="svg:descTitleMetadata" minOccurs="0"/>
produces this error:
	SystemID: /Users/phrogz/Downloads/SVG.xsd
	Location: 1291:8
	Description: cos-all-limited.1.2: An 'all' model group must appear in  
a particle with '{'min occurs'}' = '{'max occurs'}' = 1, and that  
particle must be part of a pair which constitutes the '{'content  
type'}' of a complex type definition.
URL: http://www.w3.org/TR/xmlschema-1/#cos-all-limited

The intent of the schema here seems to specify that <desc>/<title>/ 
<metadata> may appear in any order, 0 or 1 times each, before other  
children of a variety of elements. (In this case, the <use> element.)  
I'm not enough of a xsd guru to know how to handle this properly. I  
punted and replaced <all> with <choice> when  
definingdescTitleMetadata, and modified the group references to allow  
0..3 instances. This technically allows <desc /><desc /><desc />...but  
I figure a false positive is better than nothing.


7 - feFuncRType/feFuncGType/feFuncBType/feFuncAType all define a  
'type' attribute explicitly, and then reference attributeGroup  
"component_transfer_function_attributes" which also defines the same  
'type' attribute.

SystemID: /Users/phrogz/Downloads/SVG.xsd
Location: 2257:71
Description: ct-props-correct.4: Error for type 'feFuncRType'.  
Duplicate attribute uses with the same name and target namespace are  
specified.  Name of duplicate attribute use is 'type'.
URL: http://www.w3.org/TR/xmlschema-1/#ct-props-correct

I simply removed the explicit 'type' attribute from those four elements.


Finally the XSD at least _validates_ on its own.

There are other issues that could be fixed. For example, many of the  
attribute types do not actually validate their values, and instead  
just inherit from the xsd string type. For example:

   <simpleType name="EnableBackgroundValueType">
     <annotation>
       <documentation>accumulate | new [ &lt;x&gt; &lt;y&gt;  
&lt;width&gt; &lt;height&gt; ] | inherit</documentation>
     </annotation>
     <restriction base="string"/>
   </simpleType>

or

   <simpleType name="TransformListType">
     <annotation>
       <documentation>Yes, of course this was generated by a program!</ 
documentation>
       <documentation>list of transforms</documentation>
     </annotation>
     <restriction base="string"/>
   </simpleType>

Writing patterns (or other combinations) to exactly validate the  
contents of these attributes might not benefit many...but it sure  
would feel nice and pure. ;)


I've uploaded my modified versions of the svg.xsd, xlink.xsd, and  
xml.xsd to http://phrogz.net/SVG/




[1] oXygen v9.1, build 2007122116 - http://www.oxygenxml.com/
Received on Thursday, 20 March 2008 13:36:08 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT