Are there any plans for Inkscape to move away from XML namespaces when SVG 2, HTML 5 and Web Components will become widely supported and XML namespaces will get deprecated?
If this is the case, I think it would be great opportunity to clean up the current namespace mess. Ideally, I would like to see all vendors of SVG editors to agree on a common “editor” namespace that would be implemented with HTML 5 data- attributes and custom elements.
My proposal:
1. Drop “dc:", "cc:" and "rdf:" namespaces and remove any elements and attributes using them as this is just useless noise. 2. Drop "xlink:" namespace prefix (as defined by the SVG 2 spec). 3. Convert all elements in “inkscape:" and "sodipodi:" namespace to custom elements with "editor-" prefix (as defined by Web Components spec) 4. Convert all attributes in “inkscape:” and "sodipodi:" namespace to data- attributes (as defined by HTML 5 spec).
For example following SVG 1.1 document generated by current stable version of Inkscape:
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" version="1.0" width="1000" height="2000" viewBox="0 0 1000 2000"> <sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="1366" inkscape:window-height="689" id="namedview1530" showgrid="false" inkscape:zoom="0.57" inkscape:cx="542.23281" inkscape:cy="1495.4813" inkscape:window-x="0" inkscape:window-y="27" inkscape:window-maximized="1" inkscape:current-layer="svg2"/> <image sodipodi:absref="/image.png" xlink:href="image.png" width="950" height="632"/> <path inkscape:connector-curvature="0" d="M 60,10 L -40,-45"/> </svg>
... could become this in future when saved as SVG 2 document:
<graphics width="1000" height="2000" viewbox="0 0 1000 2000"> <defs> <editor-namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" pageopacity="0" pageshadow="2" windowwidth="1366" windowheight="689" id="namedview1530" showgrid="false" zoom="0.57" cx="542.23281" cy="1495.4813" windowx="0" windowy="27" windowmaximized="1" currentlayer="svg2"> </editor-namedview> </defs> <image data-editor-absref="/image.png" href="image.png" width="950" height="632"/> <path data-editor-connector-curvature="0" d="M 60,10 L -40,-45"/> </graphics>
Some related documents: - Custom elements: http://w3c.github.io/webcomponents/spec/custom/ - Proposal for improving SVG DOM: http://dev.w3.org/SVG/proposals/improving-svg-dom/ - Data attributes: http://www.whatwg.org/specs/web-apps/current-work/#embedding-custom-non-visi...
Do you think this has any chance to get adopted by Inkscape? If not, do you have any alternative plan to improve the way how Inkscape stores non-standard data in SVG documents in the upcoming post-XML future?
2014-02-02 Jarek Foksa <jarek@...3085...>:
Are there any plans for Inkscape to move away from XML namespaces when SVG 2, HTML 5 and Web Components will become widely supported and XML namespaces will get deprecated?
The current draft of SVG 2 says that a conforming implementation must implement XML Namespaces. https://svgwg.org/svg2-draft/conform.html#ConformingSVGInterpreters
Inkscape is an editor for SVG, not an editor for SVG content embedded in HTML5. Therefore I don't see it moving away from XML namespaces any time soon, if ever.
Regards, Krzysztof
The current draft of SVG 2 says that a conforming implementation must implement XML Namespaces. https://svgwg.org/svg2-draft/conform.html#ConformingSVGInterpreters
I guess it’s a matter of time when SVG 2 (or whatever comes after it) will make the XML serialisation optional in a similar fashion to (X)HTML 5. Google is already migrating Chrome’s SVG implementation from XML to HTML parser [1].
Inkscape should play nicely with the HTML 5 / Web Platform ecosystem if it wants to stay relevant in its field. It’s definitely too early to make any radical switch now since the specs are still in flux, though some legacy stuff like ref, cc and sodipodi namespaces could be dropped already in order to make SVG documents generated by Inkscape easier to work with in the most common use scenarios.
2014-02-03 Jarek Foksa <jarek@...3085...>:
http://code.google.com/p/chromium/issues/detail?id=243882 "This behavior would not conform to the SVG specification. Think of it as a crazy experiment."
Therefore we will not implement this.
Regards, Krzysztof
On Mon, 2014-02-03 at 02:45 +0100, Jarek Foksa wrote:
Inkscape should play nicely with the HTML 5 / Web Platform ecosystem if it wants to stay relevant in its field.
Inkscape's not going to be any less relevant as an svg editor or design tool without html 5 support; This is somewhat backwards.
Developers and their clients should develop inkscape or extensions that play nicely with html 5 if they want. It's a matter of need driving development.
Obviously namespaces should stay, that's just mad. ;-)
Martin Owens
Hi Jarek What do you mean by the following sentence?
- Drop “dc:", "cc:" and "rdf:" namespaces and
remove any elements and attributes using them as this is just useless noise.
Isn't better to actually use those namespaces for proper attribution and license information?
As a FYI, "Commons Machinery" [1] is working on exactly this. I helped out last summer trying to figure out those parts in Inkscape but at that time the code base was to heavy to work with instead focus is put in other software areas [2, 3]. The lessons learned from "Commons Machinery" will definitely be useful in Inkscape in the future. The project just got another year of funding and have two developers working now. Anyone with ideas and questions can join #commonsmachinery on Freenode IRC network.
[1] http://commonsmachinery.se/ [2] http://commonsmachinery.se/labs/ [3] https://github.com/commonsmachinery/
Regards
What do you mean by the following sentence? Isn't better to actually use those namespaces for proper attribution and license information?
Yes, this is reasonable way to put attribution and licensing information in an XML file that is going to be interpreted by a machine, I was arguing that consistency and interoperability with HTML 5 (which uses microdata [1]) should be more important than keeping support for Semantic Web ideas that failed to get widespread adoption.
There are many complains, especially from web developers, about Inkscape generating verbose SVG files that are hard to understand and modify by humans. On the other hand there seems to be little demand for Semantic Web features.
[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#l...
Am Montag, 3. Februar 2014, 10:47:09 schrieb Jarek Foksa:
What do you mean by the following sentence? Isn't better to actually use those namespaces for proper attribution and license information?
Yes, this is reasonable way to put attribution and licensing information in an XML file that is going to be interpreted by a machine, I was arguing that consistency and interoperability with HTML 5 (which uses microdata [1]) should be more important than keeping support for Semantic Web ideas that failed to get widespread adoption.
There are many complains, especially from web developers, about Inkscape generating verbose SVG files that are hard to understand and modify by humans. On the other hand there seems to be little demand for Semantic Web features.
I don't know if Inkscape has a written down product vision (gosh, how i dislike this term, but GIMP has started using it so it's probably well understood) but I was always under the impression that Inkscape wants to be a serious tool for high quality designs, be it DTP or logo design or anything like that, which eventually gets exported to some other format than SVG. Creating SVGs for inclusion into websites never occured to me to be a primary goal. More a neat side effect of seeing SVG adopted widely by HTML5. And for serious work you definitely need metadata handling, that has nothing to do with any semantic web stuff.
I might be wrong though and Inkscape could be aiming at these use cases. The website didn't tell me what it wants to be.
[...]
Tobias
2014-02-03 Jarek Foksa <jarek@...3085...>:
There are many complains, especially from web developers, about Inkscape generating verbose SVG files that are hard to understand and modify by humans. On the other hand there seems to be little demand for Semantic Web features.
File -> Save As... -> select Optimized SVG from the dropdown. There is an option called "remove metadata".
This extension currently does not remove unused XML namespace declarations, but I think that would be fairly simple to fix.
Generally, if you want to generate files that look like your example, the way to go is to postprocess the normal Inkscape output, rather than breaking Inkscape for everyone except HTML5 developers.
Regards, Krzysztof
participants (5)
-
Christoffer Holmstedt -
Jarek Foksa -
Krzysztof Kosiński -
Martin Owens -
Tobias Ellinghaus