FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past.
This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though.
Important things to remember:
* this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones)
* only elements in the SVG namespace will be affected; the remainder are already named unambiguously
* there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents
-mental
On Sat, 18 Dec 2004 18:02:53 -0500, MenTaLguY <mental@...3...> wrote:
FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past.
This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though.
I must have missed something, but what is the reason? Our elements are already in the SVG namespace, even without any prefix, because that is the default namespace declared in the document's root. Why add the prefix?
On Sat, 2004-12-18 at 18:14, bulia byak wrote:
I must have missed something, but what is the reason? Our elements are already in the SVG namespace, even without any prefix, because that is the default namespace declared in the document's root. Why add the prefix?
I don't plan on changing anything about serialized documents (those we read or write), but how we represent in-memory documents.
As things are now, in-memory we've discarded (or at least ignore) all xmlns declarations and use fixed prefix<->namespace mappings.
Given this, if we use the absence of a prefix to mean the SVG namespace, we can't distinguish between the SVG namespace and an undefined default namespace.
The problem this creates becomes apparent when (for example) we're given a document that looks like this:
<blah:svg xmlns:blah="http://www.w3.org/2000/svg%22%3E blah:metadata <title>some title thing</title> </blah:metadata> <blah:rect ... /> </blah:svg>
We end up interpreting the document as if it had been:
<blah:svg xmlns:blah="http://www.w3.org/2000/svg%22%3E blah:metadata blah:titlesome title thing</blah:title> </blah:metadata> <blah:rect ... /> </blah:svg>
...which is wrong and violates the XML namespaces standard.
So, the change I want to make is to have us use a prefix internally for SVG like we do for other namespaces, so we can avoid this ambiguity.
It will also force us to make certain loading heuristics explicit in the code, rather than assumed all over the place, which is not a bad thing either.
-mental
This is good, since we need to address the mixing of namespaces, like embedding SVG in XHTML.
Mozilla SVG uses this prefix already.
bob
MenTaLguY wrote:
FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past.
This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though.
Important things to remember:
this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones)
only elements in the SVG namespace will be affected; the remainder are already named unambiguously
there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents
-mental
On Sat, 18 Dec 2004 17:17:11 -0600, Bob Jamison <rwjj@...127...> wrote:
This is good, since we need to address the mixing of namespaces, like embedding SVG in XHTML.
Embedding is not a problem with the current scheme. If you have <svg> with xmlns= attribute setting the SVG namespace, it is the default for it and all its descendants. Ancestors of <svg> may have different default namespaces, it's all perfectly legal. See
http://w3c.org/TR/REC-xml-names/
for details.
Mozilla SVG uses this prefix already.
It does not matter what prefixes, if any, are used. What matters is that our SVG elements are in the namespace "http://www.w3.org/2000/svg", and our files satisfy this requirement. I don't see any need to change anything.
On Sat, 18 Dec 2004 19:44:55 -0400, bulia byak <buliabyak@...400...> wrote:
I don't see any need to change anything.
Well, not really - what does need to be changed is that we must be able to _read_ SVG elements properly regardless of what prefix they use. I haven't checked but I suspect we will fail this test. However this does not require any change in the way we _write_ SVG, and we can probably do without big changes inside. We just need to "normalize" files on load to ensure that the SVG namespace is prefixless.
bulia byak wrote:
We just need to "normalize"
files on load to ensure that the SVG namespace is prefixless.
I'm not quite sure of that.
Especially from some of the playing I did with XForms, I've come to try to respect mixing and mixed namespaces and prefixes.
There are some subtle and complex things that might be needed, especially with mixing XForms in SVG, SVG in XForms, SVG in XHTML, etc., especially once things start getting more nested. And I'm thinking that if we want to keep Inkscape up there as the premier choice for any SVG editing, or power users perhaps, we do need to keep things like that in mind.
For example, if we have <foo:image ...> and <bar:path ...> in the same doc, as long as foo and bar both are defined to the same svg namespace, shouldn't we work properly and even preserve those prefixes?
On Sun, 19 Dec 2004 13:11:54 -0800, Jon A. Cruz <jon@...18...> wrote:
For example, if we have <foo:image ...> and <bar:path ...> in the same doc, as long as foo and bar both are defined to the same svg namespace, shouldn't we work properly
Of course.
and even preserve those prefixes?
Would be nice, but I think it's pretty low priority.
bulia byak wrote:
On Sun, 19 Dec 2004 13:11:54 -0800, Jon A. Cruz <jon@...18...> wrote:
For example, if we have <foo:image ...> and <bar:path ...> in the same doc, as long as foo and bar both are defined to the same svg namespace, shouldn't we work properly
Of course.
and even preserve those prefixes?
Would be nice, but I think it's pretty low priority.
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
Trust me, I've hit this issue myself.
Jon A. Cruz wrote:
bulia byak wrote:
...
and even preserve those prefixes?
Would be nice, but I think it's pretty low priority.
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
...
Could you elaborate on why it would be necessary to preserve the prefixes? Aren't they simply shorthands for the namespaces that have no meaning by themselves? (except for xmlns and perhaps one or two other special cases)
On Sun, 19 Dec 2004 22:39:42 +0100, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Could you elaborate on why it would be necessary to preserve the prefixes? Aren't they simply shorthands for the namespaces that have no meaning by themselves?
Formally yes, but for the human who authored the XML they may have their distinct meanings. Preserving them is just a matter of being nice to our users.
On Sun, 19 Dec 2004, bulia byak wrote:
On Sun, 19 Dec 2004 22:39:42 +0100, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Could you elaborate on why it would be necessary to preserve the prefixes? Aren't they simply shorthands for the namespaces that have no meaning by themselves?
Formally yes, but for the human who authored the XML they may have their distinct meanings. Preserving them is just a matter of being nice to our users.
This is true, and it is technically possible to mix namespaces and prefixed qnames without namespaces. It'd make our "round trip" guarantees stronger if we preserved those to the extent practical (it's not possible in all cases).
But, yes, cosmetic.
-mental
On Sun, 19 Dec 2004 13:33:37 -0800, Jon A. Cruz <jon@...18...> wrote:
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
Yeah, except that we're already deep in the "after the fact" stage :)
On Sun, 19 Dec 2004, Jon A. Cruz wrote:
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
Wait a moment. We've been namespace-aware since before the fork.
We store expanded names as qnames using a predefined set of prefixes -- e.g. "{http://www.w3.org/1999/xlink%7Dhref" is represented as the qname "xlink:href". This doesn't depend on the original document's prefixes, which we mostly throw out.
[ Non-predefined namespaces do get unique prefix dynamically assigned to them when they are encountered, and for that we do use the original document prefix if it has not already been assigned. ]
[ Yes, it would have been less confusing if I'd used a different "short notation" for expanded names. It made the transition to namespace-awareness much easier though. ]
SVG was the one exception I made; it uses a bare localName -- e.g. we use "svg" to represent "{http://www.w3.org/2000/svg%7Dsvg". This was to minimize the changes to the codebase at that time; my intent was to come back and change that later. Now is the time...
I'm not really interested in preserving the original document's xmlns mappings, given that DOM1 knows nothing about them, and the namespace-aware DOM2 throws them to the wind; using the DOM2 APIs you can name stuff with any ( namespace, prefix, localName ) tuple you like, regardless of what xmlns attributes are present.
Now, we could still remember the individual prefixes in each repr node, and try to use them when serializing to the extent practical, but that's a cosmetic consieration, not a matter of standards compliance.
[ to implement DOM compliantly we do need to store prefixes somewhere -- but it could be in the DOM node impls, rather than the repr nodes they reference ]
-mental
MenTaLguY wrote:
On Sun, 19 Dec 2004, Jon A. Cruz wrote:
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
Wait a moment. We've been namespace-aware since before the fork.
Yes, I was aware of that. Hence my use of the term "namespace-saavy" instead, implying more complex handling.
[SNIP]
I'm not really interested in preserving the original document's xmlns mappings, given that DOM1 knows nothing about them, and the namespace-aware DOM2 throws them to the wind; using the DOM2 APIs you can name stuff with any ( namespace, prefix, localName ) tuple you like, regardless of what xmlns attributes are present.
Now, we could still remember the individual prefixes in each repr node, and try to use them when serializing to the extent practical, but that's a cosmetic consieration, not a matter of standards compliance.
Perhaps. Well, it's correct as far as compliance goes, but it's more than just purely 'cosmetic'. I have hit situations where mixed prefixes come up. Depending on the context, there are a few different things to do. One is to normalize all prefixes. I've done this myself in a pre-processing stage of one system. Another is to just keep things as-is.
I'll have to pour through the current code looking for how things might need to be tweaked. In the long run, I'd consider mixed prefixes under 'not losing user information', and thus a good thing to do.
On Tue, 21 Dec 2004, Jon A. Cruz wrote:
I'll have to pour through the current code looking for how things might need to be tweaked. In the long run, I'd consider mixed prefixes under 'not losing user information', and thus a good thing to do.
Well, of the alternatives I can think of, using anything except normalized qnames (as we do now) or expanded names (more verbose) would take us into a living hell of context-dependent names. Not going there.
The most tweaking that should be required is adding a "prefix" field to SPRepr/SPReprAttribute which remembers the prefix used in the original document (and, combined with the local portion of our expanded names or normalized qnames, should probably also be used to generate the qnames exposed by DOM).
If you're feeling brave, you could also rework the XML serialization code to use those prefixes in the cases where it is possible to do so without conflicts.
Both changes would be confined to xml/repr-io.cpp, although you'd obviously want to populate the prefix field (using the normalized prefix) when nodes are created from scratch as well (xml/repr.cpp).
-mental
On Sun, 2004-12-19 at 08:35, bulia byak wrote:
We just need to "normalize" files on load to ensure that the SVG namespace is prefixless.
That's what we'd already been doing.
The only problem is that making SVG names prefixless is ambiguous with non-SVG elements that have no namespace at all. As things were, those are effectively forced into the SVG namespace, which is bad.
The change I just commited simply fixes things by using prefixed qnames for the SVG namespace too.
-mental
participants (5)
-
Bob Jamison -
bulia byak -
Jasper van de Gronde -
Jon A. Cruz -
MenTaLguY