Alan Horkan wrote:
On Wed, 23 Nov 2005, Aaron and Sarah Spike wrote:
I'd appreciate suggestions on how better to voice my concern about the use of more custom markup.
No custom markup is not a good thing. Certainly not if it isn't well documented and published.
I think we can start by documenting the problem. Since you and I both care about this, let's (you and I) work together to create some sort of schema docmument that defines the sodipodi and inkscape extensions.
In many cases custom markup is bringing us closer to "powerful and convenient" and no further from "fully compliant".
Custom markup can be ignored but makes it more difficult for other software to directly interoperate and benefit from extra markup and encourage healthy competition for Inkscape.
It might be better to say that custom markup MUST be ignored. I agree that there is an interoperation problem.
It may also cause difficulties for users sharing files with people not also using the latest version of Inkscape. Given the sucess of Inkscape and slow turnaround of most distributions problems seem inevitable.
Let's be very specific. The difficulties will be of the user interaction type, not the rendering type.
Some developers most definately are. But they are diligently working within the bounds of the means.
Well it helps to know there are developers who intend to expand on their use of the inkscape namespace because I had the apparently false impression people were interested in using less of it.
The option to export to Plain SVG balances things out a little but the general enthusiasm for the SVG standard and my own overenthusiasm had me thinking there would eventually be little or no difference between Inkscape SVG and Plain SVG but I take it from your comments that is unlikely to ever happen. It seems I just plain go the wrong idea.
SVG is a display language. The inkscape namespace preserves data used in creation and user interaction in the creator application. These are very different.
The other suggestion would be to use the OpenDocument Draw namespace to support (things like additional gradient types) until such time as the SVG includes more of what is needed. Would make XSLT transformations and other conversions a little simpler but seeking out existing standards and using them is more more than creating more items in the inkscape namespace but maybe it really isn't worth doing.
Supporting gradient types not supported in SVG would violate the unwritten rule "it must render the same everywhere".
Mental said the "burden" was on me but I dont want to burden the developers or take on a burden I cannot realistically manage. If I know which way the current is flowing I can choose to follow it or get off or make minor adjustments without getting in the way of the bigger issues.
I don't think it is a burden.
I will try and choose my words more carefully
Thank you very much.
Aaron Spike