Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g".
Important note: attribute naming has not changed, it's just elements
I was pretty careful not to break anything, but I can't guarantee it; it was a pretty wide-ranging change. Let me know if anything broke.
-mental
On Thu, 23 Dec 2004 21:35:23 -0500, MenTaLguY <mental@...3...> wrote:
Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g".
You still haven't explained why is this necessary. Was Inkscape-generated SVG invalid before? No it wasn't. Why the prefix bloat? Please explain.
On Fri, 24 Dec 2004 01:08:05 -0400, bulia byak <buliabyak@...400...> wrote:
On Thu, 23 Dec 2004 21:35:23 -0500, MenTaLguY <mental@...3...> wrote:
Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g".
You still haven't explained why is this necessary. Was Inkscape-generated SVG invalid before? No it wasn't. Why the prefix bloat? Please explain.
Also, please detail in what ways, if any, our XML processing has become more compliant by your change. Can we read SVG with arbitrary SVG namespace prefix now, and preserve the prefix on save? If yes, can we leave that but remove the default non-null prefix on SVG we _generate_? If no, why change it at all?
On Fri, 2004-12-24 at 00:15, bulia byak wrote:
You still haven't explained why is this necessary. Was Inkscape-generated SVG invalid before? No it wasn't.
Yes, it was invalid in certain rare cases. We would also misinterpret certain valid documents on load.
I did give a specific example on the list earlier.
Also, please detail in what ways, if any, our XML processing has become more compliant by your change.
Only one change: we are now capable of internally representing XML elements with no namespace, which was not possible for us before (it is required of us by the "Namespaces in XML 1.1" specification -- see section 6.2 and the use of xmlns="" [i.e. an empty namespace URI]).
The only essential part of the change was in our internal representation. The accompanying change in XML output was incidental; I do plan to put it back the way it was before (mostly), but have not had time to do so yet.
Can we read SVG with arbitrary SVG namespace prefix now, and preserve the prefix on save?
This change isn't related to prefix preservation.
We've always been able to read such documents, though not preserve the prefix on save.
Please note that such preservation is not possible in all cases; it'd just be a "best effort". This is OK; prefix preservation is a cosmetic/politeness issue, not a requirement of the specification.
That's not to say prefix preservation is a bad thing to do, but it's just not as high on my list of priorities as standards compliance.
If yes, can we leave that but remove the default non-null prefix on SVG we _generate_?
Yes.
If no, why change it at all?
There's no reason for the output format to change except that it was the easiest thing to do until I can rewrite the serialization code to be more intelligent about namespace handling.
-mental
On Sat, 25 Dec 2004 03:24:38 -0500, MenTaLguY <mental@...3...> wrote:
The only essential part of the change was in our internal representation. The accompanying change in XML output was incidental; I do plan to put it back the way it was before (mostly), but have not had time to do so yet.
Thanks for the explanation. That makes sense now. I would like to nominate the restoring of null-prefix SVG namespace on output as one of the prerequisites for 0.41. The rationale is not only the bloat, but the probable existence of "namespace-naive" scripts made by users that deal with Inkscape SVG and would break if we add the svg: prefix. This is a user-visible change, and I don't want our release versions to fluctuate to and from using the prefix.
On Sat, 2004-12-25 at 13:11, bulia byak wrote:
but the probable existence of "namespace-naive" scripts made by users that deal with Inkscape SVG and would break if we add the svg: prefix.
Hrm, yes... part of me would just rather they break so they learn to fix their scripts, but that's not really very nice ^_-
While there's no trouble making SVG the default namespace for documents that don't contain non-namespaced elements (the common case), there are some difficulties for documents that do. This is because the NULL namespace can't be bound to a prefix, it can only be the default.
Long-term, the solution is to move xmlns attributes down to individual elements as needed, but that's non-trivial to implement.
Short-term, we'll just put the xmlns declarations up top, and make SVG the default namespace unless there is a non-namespaced element in the document.
I wish XML namespaces didn't have such a bolted-on feel.
-mental
participants (2)
-
bulia byak -
MenTaLguY