FAQ
Resurrecting this old thread, because I've submitted a patch with a better
approach. http://codereview.appspot.com/6856092

I'm curious if anybody can come up with a better way to do this. My patch
notes include some problems, which I've expanded on below:

1. We can't add a new Prefix field to xml.Name, because it breaks source
compatibility. Programs written with xml.Name{"space", "local"} rather than
xml.Name{Space: "space", Local: "local"} will break.
2. Because of #1, there's no good way to load namespace context at runtime.
This is something you'd want to do if you were producing XML snippets to
stuff into the middle of an XML document, or if you were parsing snippets
excerpted from an XML document. The parent elements could have modified the
current namespace and the mapping of prefixes to URIs. It may be possible
to work around this deficiency by making a fake top-level container with
that namespace context, and then filtering that top-level container out
after the call to Marshal() or Unmarshal(), but it seems inelegant. The API
really ought to contain a graceful way to accomplish this.
3. Closely related to #2, there's no way to add a convenience prefix-to-URI
mapping. This could allow the parent element to define a namespace which it
doesn't use, but which all its children do. Otherwise, each child element
will redeclare xmlns="foo".

Chris

--

Search Discussions

  • Nigel Tao at Nov 26, 2012 at 3:44 am

    On Mon, Nov 26, 2012 at 2:04 PM, wrote:
    1. We can't add a new Prefix field to xml.Name, because it breaks source
    compatibility. Programs written with xml.Name{"space", "local"} rather than
    xml.Name{Space: "space", Local: "local"} will break.
    Adding a Prefix field isn't necessarily forbidden.
    http://golang.org/doc/go1compat.html says "For the addition of
    features in later point releases, it may be necessary to add fields to
    exported structs in the API". The "go vet" tool looks for untagged
    struct literals exactly for this reason.

    --
  • Chris Jones at Nov 26, 2012 at 4:18 pm

    On 11/25/2012 8:44 PM, Nigel Tao wrote:
    On Mon, Nov 26, 2012 at 2:04 PM, wrote:
    1. We can't add a new Prefix field to xml.Name, because it breaks source
    compatibility. Programs written with xml.Name{"space", "local"} rather than
    xml.Name{Space: "space", Local: "local"} will break.
    Adding a Prefix field isn't necessarily forbidden.
    http://golang.org/doc/go1compat.html says "For the addition of
    features in later point releases, it may be necessary to add fields to
    exported structs in the API". The "go vet" tool looks for untagged
    struct literals exactly for this reason.
    Oh. Well, that's encouraging. I'll have to think about this a bit.

    Chris

    --
  • Chris Jones at Nov 29, 2012 at 5:42 am

    On 11/25/2012 8:44 PM, Nigel Tao wrote:
    On Mon, Nov 26, 2012 at 2:04 PM, wrote:
    1. We can't add a new Prefix field to xml.Name, because it breaks source
    compatibility. Programs written with xml.Name{"space", "local"} rather than
    xml.Name{Space: "space", Local: "local"} will break.
    Adding a Prefix field isn't necessarily forbidden.
    http://golang.org/doc/go1compat.html says "For the addition of
    features in later point releases, it may be necessary to add fields to
    exported structs in the API". The "go vet" tool looks for untagged
    struct literals exactly for this reason.
    I think my original assertion was wrong: Adding a Prefix field to
    xml.Name won't address the other problems. What we really need is a way
    to provide a namespace context to the Marshaler and Unmarshaler. This
    could be done by adding an argument to Encoder.Encode() and
    Decoder.Decode() (or more precisely by adding new overloads of those
    methods with an extra parameter each). It could also be done by exposing
    a public field on Encoder and Decoder which would contain the namespace
    context. The private context object in my patch is very nearly the right
    thing; it should have the current namespace, and a map of
    prefix:namespace which the caller could modify.

    Adding a context field to Encoder and Decoder should be a
    straightforward change to my patch. I'm curious if others feel it's a
    good direction also.

    Chris

    --
  • Joel Reymont at Feb 25, 2013 at 4:43 pm
    I see that the code review was closed at

    https://codereview.appspot.com/6856092

    and that the issue was 'accepted'

    https://code.google.com/p/go/issues/detail?id=3526

    I don't see the patch in the go source tree, though.

    What is the status of the patch?
    On Thursday, November 29, 2012 5:42:18 AM UTC, Chris Jones wrote:
    On 11/25/2012 8:44 PM, Nigel Tao wrote:
    On Mon, Nov 26, 2012 at 2:04 PM, <chris.j...@gmail.com <javascript:>>
    wrote:
    1. We can't add a new Prefix field to xml.Name, because it breaks
    source
    compatibility. Programs written with xml.Name{"space", "local"} rather
    than
    xml.Name{Space: "space", Local: "local"} will break.
    Adding a Prefix field isn't necessarily forbidden.
    http://golang.org/doc/go1compat.html says "For the addition of
    features in later point releases, it may be necessary to add fields to
    exported structs in the API". The "go vet" tool looks for untagged
    struct literals exactly for this reason.
    I think my original assertion was wrong: Adding a Prefix field to
    xml.Name won't address the other problems. What we really need is a way
    to provide a namespace context to the Marshaler and Unmarshaler. This
    could be done by adding an argument to Encoder.Encode() and
    Decoder.Decode() (or more precisely by adding new overloads of those
    methods with an extra parameter each). It could also be done by exposing
    a public field on Encoder and Decoder which would contain the namespace
    context. The private context object in my patch is very nearly the right
    thing; it should have the current namespace, and a map of
    prefix:namespace which the caller could modify.

    Adding a context field to Encoder and Decoder should be a
    straightforward change to my patch. I'm curious if others feel it's a
    good direction also.

    Chris
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris Jones at Feb 25, 2013 at 4:56 pm
    The CL moved to https://codereview.appspot.com/6868044 (due to my
    confusion with Go's Hg extension). As far as I know, it's still under
    review. I will happily accept suggestions, bug reports, and test cases.

    Chris
    On 2/25/2013 9:43 AM, Joel Reymont wrote:
    I see that the code review was closed at

    https://codereview.appspot.com/6856092

    and that the issue was 'accepted'

    https://code.google.com/p/go/issues/detail?id=3526

    I don't see the patch in the go source tree, though.

    What is the status of the patch?

    On Thursday, November 29, 2012 5:42:18 AM UTC, Chris Jones wrote:
    On 11/25/2012 8:44 PM, Nigel Tao wrote:
    On Mon, Nov 26, 2012 at 2:04 PM, <chris.j...@gmail.com
    <javascript:>> wrote:
    1. We can't add a new Prefix field to xml.Name, because it
    breaks source
    compatibility. Programs written with xml.Name{"space", "local"}
    rather than
    xml.Name{Space: "space", Local: "local"} will break.
    Adding a Prefix field isn't necessarily forbidden.
    http://golang.org/doc/go1compat.html
    <http://golang.org/doc/go1compat.html> says "For the addition of
    features in later point releases, it may be necessary to add fields to
    exported structs in the API". The "go vet" tool looks for untagged
    struct literals exactly for this reason.
    I think my original assertion was wrong: Adding a Prefix field to
    xml.Name won't address the other problems. What we really need is
    a way
    to provide a namespace context to the Marshaler and Unmarshaler. This
    could be done by adding an argument to Encoder.Encode() and
    Decoder.Decode() (or more precisely by adding new overloads of those
    methods with an extra parameter each). It could also be done by
    exposing
    a public field on Encoder and Decoder which would contain the
    namespace
    context. The private context object in my patch is very nearly the
    right
    thing; it should have the current namespace, and a map of
    prefix:namespace which the caller could modify.

    Adding a context field to Encoder and Decoder should be a
    straightforward change to my patch. I'm curious if others feel it's a
    good direction also.

    Chris
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 26, '12 at 3:04a
activeFeb 25, '13 at 4:56p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase