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