Hi all,
in the process of gathering a large test body for SVG data, I went to
OCAL, grabbed the whole thing, and started an automatic analysis of
the documents using a tool of mine to see how much of that data would
work with SVG Tiny 1.2. The answer is: almost none (about 2%), and I
haven't even tried to perform thorough validation. That's a real
shame since most of those documents don't need to use features from
outside SVG Tiny 1.2 since they tend to be simple, static images.
Most of these problems are due to the poor quality of code produced
by default by most authoring tools. Chief among the problems is the
constant use of the style attribute. The style attribute is totally
useless. No one should *ever* use it. Including it was a mistake, and
I certainly hope that it'll go away.
After I instructed my analysis tool to automatically fix occurrences
of the style attribute, 38% of the content became reasonably close to
being Tiny 1.2 compliant — so ~35% of problems in SVG content are due
to using a useless attribute. Surely authoring tool folks out there
could make a little effort...
The checks that caused the rest to fail are very simple, and are run
in order (so that the first error to be found causes the document to
stop being analysed: this analysis does therefore not count the
maximum number of errors for each category). Also, some of these are
not errors proper but rather things that will be ignored by an SVG
Tiny 1.2 implementation. They are included here because I'm assuming
it's not what people want from their OCAL submissions.
There were 8122 in total, of which 5061 failed (after the style
attribute had been fixed). Amongst the latter:
- 0 were not well-formed XML. That's encouraging!
- 1615 were simply not SVG documents: their root element either
wasn't in the SVG namespace or the local name was not 'svg'. This is
by far the most problematic of the issues since those are also not
SVG Full documents. This means 20% of documents claiming to be SVG in
OCAL are simply not SVG at all.
- 2705 had xlink:href on their gradients. That's a real shame since
the only use case I've heard for this is for authoring tools to be
able to round-trip gradient settings (I don't really see why, but
that's what I was told) — it has no use in content itself. Authoring
tools would likely be better off not relying on this.
- 583 had elements not in Tiny. Those are probably fine if they use
the corresponding advanced features.
_ 185 made use of the class attribute, or of the opacity property
but not on . These are likely harmless.
Should we coordinate with OCAL to promote content that is of higher
quality and that works on mobile devices? I'd be happy to contribute
a few simple rules, or else Björn's profile XSLT could be used.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
Yahoo! Groups Sponsor ~-->
Protect your PC from spy ware with award winning anti spy technology. It's free.
http://us.click.yahoo.com/97bhrC/LGxNAA/yQLSAA/1U_rlB/TM
~->
-
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
