encoding/xml: add generic representation of XML data

[fluhus]

It would be helpful to have a more 'natural' data-object for XML data, so that all the information is preserved. Something like the DOM nodes in javascript.

Here is an implementation of what I would expect an XML parser to return:
https://github.com/fluhus/gostuff/tree/master/xmlnode

What do you think? Can we add such a feature to the standard XML parser?

[fluhus]

Just found something similar here:
https://godoc.org/golang.org/x/net/html#Node

Would be great to have something of that kind for XMLs as well.

[rsc]

I agree: package xml could use something like package json's ability to unmarshal into interface{}. What that is I'm not sure. I think a reasonable starting point would be something minimal like:

// An Element represents the complete parse of a single XML element.
type Element struct {
    StartElement
    Child []Child
}

// A Child is an interface holding one of the element child types:
// *Element, CharData, or Comment.
type Child interface{}

I'm not sure it makes sense to add all kinds of navigation help on top of this. The more specialized it is, the more likely it is to not work for a significant number of users.

Edit: fixed s/*Node/*Element/ in the comment on Child.

[fluhus]

I agree about simplification.

Maybe node types can follow what the tokenizer currently returns.

You can see my implementation here (that's what I use for my work). It offers the information that the tokenizer can handle plus children and parent, with only a single exported type (Node). That's the simplest interface I could come up with for representing the different types of data.

Would be happy to hear your opinion.

[rsc]

I saw your implementation, and I think it's too complex. There's no need for an interface. What I wrote above is significantly simpler and it does follow what the tokenizer currently returns.

[fluhus]

Thanks for your comment!

I trust your solution so I won't argue too much, but can you explain why your approach is simpler?

As far as I understand it exposes more types (involves users with token types while my representation encapsulates them), and requires type-checks in code that uses it. How is that making things easier for users?

To demonstrate, here is what traversal looks like using my library:

// Only one type involved - Node - encapsulates the rest of the XML package.
func traverse(n Node) {
  doTextSearch(n.Text())
  for _, child := n.Children() {
    traverse(child)
  }
}

And with your solution I guess it would look something like (correct me if I am wrong):

func traverse(c Child) {
  // Need to understand the different types and their structure.
  switch c := c.(type) {
  case CharData:
    doTextSearch([]byte(c))
  case *Element:
    for _, child := range c.Child {
      traverse(child)
    }
  }
}

Can you specify use cases that would be simpler to solve using your approach?

My library is always available so I won't argue :) but I am happy to learn from your insights.

[rsc]

What's simpler is how much users have to read to get started and how much they have to remember to keep using the API. Better to reuse the concepts already present in the API (specifically in the definition of Token) than to create a whole separate API with a rather large interface definition to learn and understand.

[fluhus]

Understood. Thanks for sharing your thoughts!

[cannona]

If we truly want a way to losslessly represent XML data, don't we need a way to represent empty-element tags? I.E. we need to have a way to distinguish between and . Or perhaps that level of losslessness isn't a requirement for what you are proposing.

[cannona]

Oops. Let's try that again.

I.E. we need to have a way to distinguish
between <tag></tag> and <tag/>.

[rsc]

I don't think we're talking about lossless. If you needed lossless you'd also have to keep track of how every literal character was written: A vs A and so on.

[cannona]

Makes sense. I just assumed that when @fluhus said "It would be helpful to have a more 'natural' data-object for XML data, so that all the information is preserved," he really meant all

[adg]

Is anyone interested in moving this forward? If so, please write a proposal doc.