[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20339: sxml simple: sxml->xml mishandles namespaces?

From: tomas
Subject: bug#20339: sxml simple: sxml->xml mishandles namespaces?
Date: Tue, 21 Apr 2015 11:44:38 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hash: SHA1

On Tue, Apr 21, 2015 at 11:24:03AM +0200, Ricardo Wurmus wrote:
> Hi Tomás,
> address@hidden writes:
> > When transforming SXML to XML, namespaces don't seem to be handled
> > properly:
> >
> [...]
> >
> > The problem is that SXML used the concatenated (full) namespace with the
> > name as tag (and attribute) names for namespaced items. When serializing
> > to XML it should try to find abbreviations for those namespaces and issue
> > the corresponding namespace declarations.
> >
> > Instead, sxml->xml tries to split the (namespace:name) combination
> > at the first colon and to check the name -- and fails miserably at
> > (namespace:name) combinations à la "http://www.w3.org/1999/xlink:href";
> > (procedure check-name). Since there are two colons, the name part
> > has now a colon.
> xml->sxml has an optional #:namespaces argument, where you can pass an
> alist of keys to URLs to be used in the sxml output:

Aha. Didn't know about this one, thanks. Yes, the problem is that SXML
loses the link to the "real" namespaces: the application around it has
to keep track of that.

> Passing this to sxml->xml yields:
>   <svg:svg>
>     <svg:rect y="5" x="5"
>               width="20"
>               stroke-width="2"
>               stroke="purple"
>               id="rect1"
>               height="20"
>               fill="yellow" />
>     <svg:rect xlink:href="#rect1"
>               y="5" x="30"
>               width="20"
>               stroke-width="2"
>               stroke="purple"
>               ry="5" rx="8"
>               height="20"
>               fill="blue" />
>   </svg:svg>

Yes, this looks "nearly" right, except...

> Unfortunately, sxml->xml will not replace the namespace abbreviations,
> nor will it add appropriate xmlns attributes, so "svg" and "xlink" are
> devoid of any meaning.


> Since xml->sxml accepts a namespace alist I suppose it would make sense
> to extend sxml->xml to do the same.

This is more or less what I do in my proposed patch (it's in the bugs
mailing list as address@hidden). It passes around an alist of
(namespace . abbrev) associations (it's inverted wrt #:namespaces in
xml->sxml). Only that the abbreviations are "generated" as ns1, ns2
and so on (and the namespace declarations are woven into the attributes

So far not reply to my bug report, but this gives me the chance to
bikeshed my patch to death :-P

Thanks for looking into that -- and for prodding me into looking at
more sources :)

- -- t
Version: GnuPG v1.4.12 (GNU/Linux)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]