I've deprecated methods and fields that will be removed, would have changed access level, or will have different parameter types. I did that in 4.4.0-SNAPSHOT and not in 4.3.0 as 4.3.0 is already released.

Changes for now are in branch xmltools-18 for a review.

Good point about version.

@andrzej.wojcik Are we dropping Comparator interface?

	@Deprecated
	@Override
	public int compareTo(Element elem) {
		return toStringNoChildren().compareTo(elem.toStringNoChildren());
	}

Are we dropping XMLNodeIfc interface?

	// Deprecated due to change of parameter type from XMLNodeIfc to Element
	@Deprecated
	public void addChild(XMLNodeIfc child) {]

We are dropping Compararor especially as order of attributes is not fixed, so comparison may be returning incorrect values.

As for XMLNodeIfc we are going to use it internally (see addNode()) but I wouldn't expose it if possible. Children as elements as List<Element> is returned by getChildren() and CData is CData. I would keep those separate. In this particular case we would be accepting Element that implements XMLNodeIfc, but in my opinion addChild() should accept only Element.

We are dropping Compararor especially as order of attributes is not fixed, so comparison may be returning incorrect values.

But attributes are just a Map<String,String> here? Pondering it - order of children in XML is significant so I don't see much point in Comparable here (?)

As for XMLNodeIfc we are going to use it internally (see addNode()) but I wouldn't expose it if possible. Children as elements as List<Element> is returned by getChildren() and CData is CData. I would keep those separate. In this particular case we would be accepting Element that implements XMLNodeIfc, but in my opinion addChild() should accept only Element.

+1

From what it looks we need XMLNodeIfc just to handle CData?

Shouldn't we also deprecate public void setAttributeStaticStr(String elementPath[], String att_name, String att_value) {} ?

But attributes are just a Map<String,String> here? Pondering it - order of children in XML is significant so I don't see much point in Comparable here (?)

Comparable used toStringNoChildren() that means it used just attributes for comparison even without ordering. I do not see how we could implement comparison on Element so it is more reasonable to deprecate and just leave it to the user to implement correct comparator for their use case.

From what it looks we need XMLNodeIfc just to handle CData?

No, we have List as each Element may have subnodes that are either CData or Element and their order mattters, ie.: <x>1<y/>2</x> is different from <x>12<y/></x> so we need CData and Element in a single list to not lose their order - for that we use XMLNodeIfc.

Shouldn't we also deprecate public void setAttributeStaticStr(String elementPath[], String att_name, String att_value) {} ?

I was wondering about it, but I think it may be used in many places... but sure we can deprecate it as well.

But attributes are just a Map<String,String> here? Pondering it - order of children in XML is significant so I don't see much point in Comparable here (?)

Comparable used toStringNoChildren() that means it used just attributes for comparison even without ordering. I do not see how we could implement comparison on Element so it is more reasonable to deprecate and just leave it to the user to implement correct comparator for their use case.

Makes sense.

From what it looks we need XMLNodeIfc just to handle CData?

No, we have List as each Element may have subnodes that are either CData or Element and their order mattters, ie.: <x>1<y/>2</x> is different from <x>12<y/></x> so we need CData and Element in a single list to not lose their order - for that we use XMLNodeIfc.

This is what I meant by " just to handle CData " :)

Shouldn't we also deprecate public void setAttributeStaticStr(String elementPath[], String att_name, String att_value) {} ?

I was wondering about it, but I think it may be used in many places... but sure we can deprecate it as well.

I'd be in favour of deprecating it. If someone needs to set attribute deep inside element IMHO it's better to get that element via top-level api and then set the value via setAttribute(key,val). Basically it would result in more explicit code and less ways to do the same thing which would result in cleaner API IMHO.