This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hi, hope this is the right place to ask. I need your help. The file is normal but seems bugged in preview.What can be the problem? Tal (רונאלדיניו המלך, talk) 22:50, 8 July 2018 (UTC)
Template:Valid SVG creates a link to the Markup Validation Service (W3C Markup Validator)
... which seemingly always generates a DOCTYPE Declaration Warning (if a DOCTYPE declaration is included in a SVG), while using a slightly different base-URL for the same Service does not produce such Warnings.
Take, for instance, an upload of which the source code is valid, such as:
If one uses this link to check the upload using the Markup Validation Service (W3C Markup Validator), then one receives no warnings at all("Result: Passed").
The following notes and warnings highlight missing or conflicting information which caused the validator to perform some guesswork prior to validation, or other things affecting the output below. If the guess or fallback is incorrect, it could make validation results entirely incoherent. It is highly recommended to check these potential issues, and, if necessary, fix them and re-validate the document.
DOCTYPE Override in effect!
The detected DOCTYPE Declaration "<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">" has been suppressed and the DOCTYPE for "SVG 1.1" inserted instead, but even if no errors are shown below the document will not be Valid until you update it to reflect this new DOCTYPE.
That is, of course, if one has such a DOCTYPE Declaration in the SVG file.
I am looking forward to your comments on this discrepancy.
P.S.: To specify whether or not any SVG is valid, and to specify the methods used to create any SVG, there are so many different templates, transclusion parameters, and options on Wikimedia Commons that I am close to calling it a mess. If one looks at the usage of those templates, one can also notice that: Commons users paste the boxes all over the place on the File Upload pages, and further more they often claim that some SVG is valid, while in fact it is not when you just check it. I wonder why the checking of the markup validation can not be automatized?
Hello Vincent Mia Edie Verheyen, this is because the W3C Markup Validator doesn't recognize SVG without DTD anymore (so the template has the option as default). This is only a warning you can ignore. You don't need to create your own template too, the problem is known and a solution is in search. -- User: Perhelion13:50, 11 July 2018 (UTC)
@Vincent Mia Edie Verheyen: Thanks for the bug report. The {{Valid SVG}} template worked well until a couple months ago. That's when the W3C validator developed a bug and could no longer handle SVG files that did not have a DOCTYPE. The problem was reported to W3C, but W3C has not fixed the bug yet. Consequently, a workaround was applied to {{Valid SVG}}. The workaround instructs the validator to use the SVG 1.1 DOCTYPE, and that causes the DOCTYPE override message you see. The instruction gets the W3C validator to check all SVG files, but the check may produce warnings and errors that would not have been present a few months back. Ideally, W3C will fix its validator, but other options are possible. Glrx (talk) 14:42, 11 July 2018 (UTC)
I recently made a plan for a stadium File:Northumnerland Development Project.svg to illustrate articles like Tottenham Hotspur Stadium. However I notice that lettering does not come out right in the thumbnail image in the article. I have no idea what the issue is, and as this is the first time I have ever made a svg file with Inkscape (and not a very good attempt at the job), I must have made some mistakes somewhere. Can anyone help? Hzh (talk) 12:05, 14 July 2018 (UTC)
@Hzh: You should use fontsizes above 20px (font-size="20"), see File:Fonttest-Kerning.svg. (You are using font-size="3.5" up to font-size="4.8") Inkscape uses different units and therfore displays different numbers, but if you open the SVG file in any texteditor you will see: font-size:4.12943888px, try to use at least font-size:10px.) — Johannes Kalliauer - Talk | Contributions15:28, 14 July 2018 (UTC)
I see that you have fixed the issue, thank you very much. I was learning how to use Inkscape as I go, so everything was done a bit haphazardly, but it's puzzling to me as fontsizes above 20px be seem too big for the figure. (I was also having problem using OpenStreetMap which is why it ended up as it is, but that's another issue). Hzh (talk) 15:54, 14 July 2018 (UTC)
@Hzh: The font-size is not your fault, the render does not work precisely. The Render-Software-Bug is fixed since March, but Updating the software on Commons makes some problems. (It's easier to correct the svg-files).
This section is resolved and can be archived. If you disagree, replace this template with your comment. — Johannes Kalliauer - Talk | Contributions 17:04, 14 July 2018 (UTC)
Need for a way to add metadata without making the markup of an SVG invalid
I have, up until today, not found any SVG uploaded to Wikimedia Commons that both:
is valid (checking using the “Markup Validation Service (W3C Markup Validator)”); as well as
Is anyone aware of a file uploaded to Wikimedia Commons which satisfies both of these conditions? I would be most interested in checking it out. If there is no such file, would anyone be interested in developing a guideline for new users to include structured metadata into an SVG while not thus making the file's markup invalid? Kind regards, Vincent Mia Edie Verheyen (talk) 21:02, 11 July 2018 (UTC).
@Perhelion: I just got the idea of putting the meta-data in a block-comment:
<!--metadata here-->
Of course, we couldn't really call that "structured" metadata ... but we could create a small coding guideline on what to structurally include in this manner. At least it keeps the SVG valid. Kind regards, Vincent Mia Edie Verheyen (talk) 14:49, 12 July 2018 (UTC).
Please do not embed metadata in comments. Comments are not data.
Adding metadata does not make the markup SVG invalid. The SVG 1.1 DTD is just too strict for metadata.
Document Type Definitions (DTDs) are difficult to extend with metadata or other schemes. Previously, one could DTD validate metadata by using an internal subset to extend (subset) the SVG DTD (example skeleton):
That made the DTD validators happy, but IIRC a couple years ago MediaWiki started rejecting uploads that had parameter entities (% entities; only-within-the-DTD entities), so it is no longer an option for Commons. (The Document Object Model (DOM) has also shifted away from ordinary entities.)
So the situation today is W3C DTD validation will fail for Commons SVG files with DOCTYPE and metadata:
So do not include a DOCTYPE in your SVG and use the W3C nu validator.
As stated above, W3C has been given a bug report because its DTD validator now fails when it tries to pass an SVG without DOCTYPE file to its nu validator.
I am not objecting to DOCTYPE for the reasons you give. Quite simply, DOCTYPE DTDs that do not describe the syntactic contents of the XML file should not be used. If the DTD does not match the file, it should not be present.
Including a DOCTYPE in an XML file implies that the XML file will validate with the supplied DTD. That works for plain SVG files, but it does not work if the SVG file has extensions such as <metadata> or sodipodi elements and attributes. The DTD checks for strict conformance, and any extensions violate that conformance. SVG files with extensions will not validate against the SVG 1.1 DTD. If your SVG file includes metadata, then do not use a DOCTYPE.
Many graphics programs insert the SVG 1.1 DOCTYPE but include extensions and metadata. Although those programs generate usable SVG, they automatically produce "invalid" XML documents. In some XML environments, programmers must explicitly turn off validation to read non-conforming documents.
DTDs do not understand namespaces. The strings svg:path and path are not the same to a DTD validator. Although DTDs were a selling feature of XML, XML namespaces have sidelined DTDs. The modern viewpoint is to not use a DOCTYPE. DOCTYPEs are no longer recommended for HTML, and SVG has followed suit. (Namespace-aware alternatives such as xsi:schemaLocation are possible.)
So if your file is only SVG and nothing else, include a DOCTYPE, and the file will validate. If you add anything else and use the standard DTD, then the file is not valid and will not validate. If you want to include metadata, then do not include a DOCTYPE.
W3C was aware in 2006 that its SVG validator should not expect a DOCTYPE. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=3663 and expecially "namespace awareness is needed and DTDs are either suboptimal or clearly inappropriate".
You gave 3 options for metadata. The first is the appropriate one. Information about the file should be in metadata elements. Current practice is to use Resource Description Framework (RDF) with vocabularies from Dublin Core and Creative Commons.
Your options 2 and 3 have problems because there is no common syntax for such data. Metadata should be understandable by a machine. Option 2 abuses the id attribute, so it has problems. It cannot specify the author of another work: that would create two title elements (which is legal) but there would be two elements with id="author" (which is illegal). Option 3, putting important information in comments, is a poor practice. Comments are notes that machines are supposed to ignore. Furthermore, options 2 and 3 would have to reinvent RDF.
For Commons, the goal of validation is to make it more likely that the file will display correctly on several user agents. Commons recognizes that many of its submissions were made with Adobe Illustrator or with Inkscape. W3C also recognized that reality. Consequently, Commons is OK with SVG files that have extensions used by those tools.
Up until a few months ago, the template on Commons could validate against the stated DOCTYPE or (if no DOCTYPE) validate against a reasonably extended SVG specification (one that tolerates Adobe and Inkscape extensions). Then things broke at W3C. Files that used to validate would hang the validator. A reasonable workaround was done, but it had an unwelcome side-effect of saying files that used to validate were no longer valid. Somebody would click the link produced by {{ValidSVG}} and be told the file had 32 errors; that's confusing. Modifying the template to use the nu validator (which ignores an existing DOCTYPE) is an improvement. Most files that had SVG 1.0 or SVG 1.1 DOCTYPEs should still validate (files that subset the DTD could have problems), and files without a DOCTYPE will validate if they validated before.
Perhelion and other's work on Commons has been good if not stellar. If W3C fixed its bug today, the templates could go back to their old definitions tomorrow. But further work at Commons is not indicated yet. Commons could set up its own validator, but why do that if others provide the service? W3C has a strong incentive to provide the service and keep it up to date. (Take an en.WP page and run it through W3C's validator.) Commons could do a hack where it scans the SVG file; if it finds a DOCTYPE, then it could send the file to the DTD validator; otherwise, it could send the file to the nu Validator. That's more work, and it has little payback; direct to nu validator is a reasonable fix (it may mess up options, but that should be minor). And if W3C fixes its front-door validator, the work would be obsolete. The best place to fix the issue is at W3C. Encourage them at https://www.w3.org/Bugs/Public/show_bug.cgi?id=30257
To put it another way, the Commons template can reasonably use the results of the nu validator to measure the validity of all SVG files. If somebody wants to check a file against a strict DOCTYPE, then use W3C's other tools.
@JoKalliauer: Hmm. Turnabout is fair play; you pulled some RDF from one of my files. There are many ways to express statements in RDF, and the subset above was only showing how to validate one of those ways.
The subset I gave was only a skeleton to get a simple example to work. You can run this code (the above skeleton modified to use rdf:about instead of about (the RDF spec changed)) through W3C the validator:
Your example has validation errors because there are no definitions for elements such as cc:Work. My example subset only defined cc:Creator and it used rdf:Description with Dublin Core attributes instead of DC elements.
Here's your example with additional definitions to validate your RDF example:
Thank you very much. I like "happy validators", and keeping metadata is important, now I know a solution to fullfill both. I will take a closer look later on later, maybe in future I will use metadata more often. — Johannes Kalliauer - Talk | Contributions21:59, 16 July 2018 (UTC)
Guidelines
@Glrx: Could you please use your knowledge, as you have demonstrated in this discussion, to formulate a guidelie for metadata in SVGs on Wikimedia Commons? It would be really helpful to know all of the possible metadata categories that could be included. Many thanks for your help, Vincent Mia Edie Verheyen (talk) 09:57, 23 July 2018 (UTC).
@Glrx: If I try to add the code you suggested, and upload it, I get the errormessage "The XML in the uploaded file could not be parsed.", which seems to be a bug of WikiMedia. (I did not had any problems on Commons:Commons_SVG_Checker, but uploading to Wikimedia fails.)
@Glrx: In File:Test.svg#filehistory the last file shows still the Test-file (or my cache did not update?), "?action=purge" might crash the sever (since there are too many versions).
One must distinguish the different validators and recognize their limitations. In addition, one must recognize WMF's security measures prevent the upload of valid SVG files. It is difficult to negotiate all of the problems.
The Commons {{ValidSVG}} template uses this validator, but it currently works around this problem by instructing the validator to always use the SVG 1.1 DTD (no internal subset). Consequently, only simple SVG files will validate and any metadata or extensions are reported as errors. Even if an internal subset could be present, it would be ignored.
These are schema validators that use RelaxNG schemas (.rng files).
They can be told to use specific schemas (definition files similar to DTDs) to check a file
They ignore DTDs, so any extensions specified in an internal subset are lost.
They either check or ignore a limited number of extensions: RDF, sodipodi, inkscape.
They can be told to ignore elements and attributes in specific namespaces
IIRC, the user interface is confusing. It will check SVG files specified with a URI, but it will not check SVG files by pasting the content into a text box. SVG-pasted files are checked as HTML and fail.
You mentioned File:SVG Test TextAlign.svg. It does not have a DOCTYPE, so one of the nu validators must be used:
Uploading the file to File:Test.svg will provide a link to the validator.nu engine.
Commons imposes some security measures. For example, an SVG file might contain some malicious JavaScript code, so Commons tries to prevent such files being uploaded and distributed by Commons. Apparently Commons believes that <!ENTITY # …> definitions are evil, and Commons will block them from upload. That's another story.
@JoKalliauer: I believe the failed to parse "error" is Commons rejecting the parameter entitythe ATTLISTs.
So the advice is simple but not consoling. Don't include a DOCTYPE if you add metadata or use extensions. Check the file with a nu validator rather than a DTD validator. If you click the link provided by {{Valid SVG}}, then ignore any errors about RDF, Inkscape, or sodipodi.
I believe the metadata should be RDF that generally follows the Creative Commons guidelines, but that guidance is weak even for simple cases. (CCRel 1.0 gives some background and guidance, but it covers a lot of formats. Sadly, it may offer more confusion than help.) I cannot give specific advice because I'm not sure what is best, and I believe the issue is still in flux. When there is one artist, that artist is the dc:creator, but if there are two artists, should there be two dc:creators or just one creator with the two artists grouped in an rdf:Bag? Or should one of the artists be labelled dc:contributor. Should people be represented as simple strings ("John Q. Public") or should they have a dc:agent wrapper around them? Should the date be of the original work or the most recent modification?
Without stating exactly what the statements should be, here are some statements that I may include (dc is Dublin Core and cc is Creative Commons):
. dc:creator "John Q. Public" (or a URI)
. dc:contributor "John Doe" (or a URI)
. dc:date "2018-07-23"
. dc:publisher "Wikimedia Commons" (or a URI)
. dc:source URI
. cc:license licenseURI (license is complicated; CC0 is not Public Domain)
. cc:attributionURL URI on Commons (CC-BY creator may specify a particular URI)
. cc:attributionName URI of Commons User (CC-BY creator may specify a particular name)
This section is resolved and can be archived. If you disagree, replace this template with your comment. — Johannes Kalliauer - Talk | Contributions 17:04, 14 July 2018 (UTC)
%E2%80%9D_to_%E2%80%9CValidator.nu%E2%80%9D._Undo_revision?){kind=link}
”_to_“Validator.nu”){kind=link}
![[1]](https://github.com/RCollins13/HumanIdiogramLibrary/blob/master/vector/chr1_idiogram.svg){kind=link}
Done