No? But I think that if you have substructure, like a position or can reasonably have multiples of the thing, it should be a tag.

I generally try to reserve attributes for metadata. That is, data about the data contained in the tag.

There is none. In general, the main difference is that elements are all ordered wrt each other, while attributes are not. This ought to make the choice simple, except that attributes also cannot contain nested data structures.

A particularly unusual take is to ignore the difference and allow either attributes or child elements as different ways to do the same thing. This is what XAML does; e.g. this:

   <Button Content="Foo" />

is identical to:

   <Button>
       <Button.Content>Foo</Button.Content>
   </Button>

There is for user-viewable markup-enhanced documents, like SVG and HTML - which is pretty much what you experience with SVG and HTML authorship by hand.

If data should be presented to the user by a user agent that doesn't understand extensions to the markup, it should be using text nodes.

If it is a modification to a subset of a block of text, such as emphasizing a word, it should be a new element.

If it is a block of semantic metadata, you would structure that as a hierarchy of elements with attributes.

Otherwise, it is usually an attribute on an existing element.

SVG is a bit of a zany format in XML because so much of the content is points or encoded data, which get stuffed in some truly epic attributes.

XML wasn't really made for pure data formats, even though shoehorning that in was the majority of the market's effort.

I'd say if it's for general data exchange, I'd shy away from attributes as much as possible. Not all tools handle them well, and XML novices can get confused about their usage.

Using plain tags is so obvious that just about anyone can get it, and in my experience there's no real advantage to using attributes.

At least that's my experience at work, where we use XML as our primary integration format for others that want to deliver data to our system. When going through with a new customer, the few attributes we have almost always cause some kind of issue or misunderstanding.