[golang-dev] Re: code review 6868044: encoding/xml: namespace handling (issue 6868044)

Hello rsc@golang.org, chris@cjones.org, n13m3y3r@gmail.com (cc:
golang-dev@googlegroups.com),

Please take another look.


https://codereview.appspot.com/6868044/

I would like to drop Context from the API. Can we do that?
It seems to me that even if you're in the middle of a document you can
just introduce new prefixes as needed.

Russ

Thanks for reviewing. I don't know how you'd introduce a new prefix
other than with a tag, and tags are static and difficult to use on an
as-needed basis.

But the problem is really more about introducing existing prefixes
rather than new ones. Imagine you're emitting XML that's going to go
into the middle of an XML doc, and some prefixes have already been
declared in that doc. It would be clumsy to redeclare those prefixes, or
to declare new ones for the same namespaces. An XMPP implementation
almost requires this capability, and it's likely that other XMPP
implementations wouldn't interoperate with those clumsily redeclared
namespaces.

An XMPP conversation consists of two XML documents, each being sent the
opposite direction over the connection. The client's "document" starts
with this:

<stream:stream xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams" ...>

Then, over the life of the connection, the client sends its commands to
the server as a series of XML elements, all of which are implicitly in
the "jabber:client" namespace. Notice there's no end tag for
<stream:stream>. That means you can't send it using xml.Marshal() or
xml.Encoder.Marshal() -- those both send end tags for every element. So
you have to output that <stream:stream> header without going through
Encoder. Somehow, Encoder needs to know that you've declared two namespaces.

I'm not in love with Context, but I don't see a better way to do it. A
full implementation of XML namespaces requires that you have something
functionally equivalent to Context. The ability to stop and start in the
middle of a document means we need to expose that information to the
user somehow.

Assuming you or somebody else doesn't see a better alternative to
Context, here's a related question: Should we use type aliases on the
keys and values of Context.Map? Currently it's map[string]string, and
Encoder uses it as namespace -> prefix while Decoder uses it as prefix
-> namespace. That feels dirty to me, and likely to cause confusion.

Chris

Perhaps, but perhaps not.

I think that if you need to send a <foo> in the jabber:client name
space, you can always send

<foo xmlns="jabber:client">

instead of needing to know what the outer version is called.

Russ

You're right, of course -- a document with redundant namespace
declarations is technically compliant with the spec. Let me marshal
(heh) my arguments against that, though:

In my specific case, I'd worry that other XMPP implementations wouldn't
interoperate with the extra namespace declarations. Such implementations
would be buggy.

In XMPP, every stanza I send would be qualified by the redundant
namespace declaration. That's 22 bytes of extra data for every command
sent to the server. I guess whether that's excessive depends on where
you're coming from. It could be a lot more redundant data in other
environments.

From a purely aesthetic perspective, it seems icky to generate those
redundant declarations, with no reasonable way of suppressing them.

For unmarshaling, this all may be more of a concern. The current
approach, which is to stuff unknown prefixes into the namespace field of
xml.Name, is imprecise. I could construct a document that would cause
the parser's output to be wrong, if you started parsing after the first
element:

<x xmlns:foo="ns1" xmlns:ns2="foo">
<foo:z/>
</x>

And there's no straightforward way for me, as a user of encoding/xml, to
set up the parser to do the right thing with this document if I have to
parse an excerpt of it.

Chris

It's easy to handle the parsing half. Use the xml Decoder to read the
first element, and it will have the appropriate context.

For the printing half, I'd still like to avoid adding new API until we
have a demonstrated need. Any XMPP implementation must parse XML, and
what I've suggested is valid XML. It's true that it adds the 22 bytes
or so to each message, but I've seen what XMPP messages look like: no
one will notice 22 extra bytes. Also, if you're doing XMPP over TLS
it's all getting compressed anyway.

Russ

I'll modify the patch accordingly and resubmit.

Chris

Hello rsc@golang.org, chris@cjones.org, n13m3y3r@gmail.com (cc:
golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go


https://codereview.appspot.com/6868044/