[Clipart] Does openclipart.org have invalid SVG content?

[Jon Phillips]

On Wed, 2006-10-11 at 14:20 +0100, Stephen Silver wrote:
> Jon Phillips wrote:
> 
> > On Tue, 2006-10-10 at 12:25 +0100, Stephen Silver wrote:
> 
> > > You need to add the correct document type: many of the files are
> > > SVG 1.0 rather than SVG 1.1, and you will get a validation failure
> > > if you add the wrong one (because the DTD will conflict with the
> > > 'version' attribute).
> 
> > Hmmm...is there an option for this on the validator to pick up the right
> > doctype prior to checking the document...or should we pick one solid
> > doctype for our collection and make sure all our clipart conforms?
> 
> The correct doctype should be added to the file before validation,
> after stripping out the non-SVG stuff, as per the spec.  The correct
> doctype can be determined by checking the 'version' attribute (and
> if there's no 'version' attribute, then either of the two standard
> doctypes should be OK).

Ok, I think we should run validation on the clip art first and then
react accordingly. There is also some level of subjectivity to testing
the images and making sure visually, that they are not altered
adversely.

> > I think SVG 1.1 should be what we support.
> 
> Why not support both SVG 1.0 and SVG 1.1?  Admittedly, they are
> almost the same thing - but converting SVG 1.0 to SVG 1.1 still
> seems like an unnecessary complication.

Yes, I agree, we should support all the SVG specs and go for doctype
validation/compliance.

> > > The SVG 1.0 and SVG 1.1 specs have appendices on conformance
> > > criteria.  Have you looked at these?  It's similar to what you
> > > are doing, but not quite the same, and you are probably getting
> > > validation errors on many files that are in fact conformant.
> > 
> > Oh, could you help us sort this out? Would you like to help us
> > develop this tool?
> 
> You can already find many non-conforming files using the SVGscan
> tool I developed for this purpose.  Nothing is done about these
> files.  There isn't much point in developing another tool to find
> even more broken files until there is a system in place to deal
> with them.

Where is your SVGscan tool anyway? I want to get all of these
consolidated into our tools folder and do a release of our tools...

> That said, it would be good to have a tool that checks for SVG
> conformance (and this involves much more than just checking that
> a suitably modified copy of the file is valid XML), and I may
> be willing to help with this at some point.  But right now the
> priority for OCAL has to be to develop a system for dealing with
> broken files, rather than developing a more refined method of
> finding them.

Ok, please help us with this :)

Jon

-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon at gristle.org
IRC: rejon at irc.freenode.net