Would anybody mind taking a look at my XML structure?

Question

I am relatively new to this but I was hoping somebody could offer up a good critique of this XML structure I put together. I am not looking for anything in depth but rather if somebody notices anything inherently wrong with the structure (or any tips to make it better) I'd greatly appreciate it.

We have a large amount of products that we wholesale out and our customers were looking for a data feed to incorporate our products into their websites.

<product modified="">
    <id></id>
    <title></title>
    <description></description>
    <upc></upc>
    <quantity></quantity>
    <images>
        <image width="" height=""></image>
        <image width="" height=""></image>
        <image width="" height=""></image>
    </images>
    <category>
        <name></name>
        <subcategory></subcategory>
    </category>     
    <sale expiration="">yes</sale>
    <msrp></msrp>               
    <cube></cube>
    <weight></weight>
    <pricing>
        <tier>
            <pack><pack>
            <price></price>
        </tier>
        <tier>
            <pack><pack>
            <price></price>
        </tier>         
        <tier>
            <pack><pack>
            <price></price>
        </tier>
    </pricing>
</product>

We sell in 3 different pack sizes hence the pricing node.

Answer 1

I think <pack> and <price> could be attributes to <tier>, or preferable simply remove <tier> and have <pack> and <price> as attributes of <pricing>;

<tier pack="some-pack" price="some-price" />

or

<pricing pack="big-pack" price="high-price" />

Not fully sure if that makes sense to you (or for your business), but would clean up the XML a little.

Answer 2

If you move all attributes (i.e/ modified, width, height and expiration) to elements, then customers can automatically map your product specification 1:1 to JSON or their internal object. In fact one day you may consider providing JSON or protocol buffers as alternative format for your data, and plain XML structure will allow to make transformation automatically. A relief if you have dozens of various XML formats (that may change from time to time). It is very rare that people are reading XML and extracting information from it manually, so there is absolutely no need to put XML beauty first.

Answer 3

1. It's not clear to me that you're consistently using child elements to indicate one-to-many relationships. If a product can have multiple categories, then fine, but if it can only have one you'd be better off with single elements named categoryName and categorySubcategory. Otherwise someone somewhere will misunderstand the semantics of your XML and you'll have a problem to fix that wouldn't have arisen if you were consistent.

2. Speaking of which, you should have a plan in mind for what happens when you need to use multiple words in your tag names.

3. It's not clear to me that you have a consistent reason to use attributes versus elements. I suspect that you've given the image elements width and height attributes because that's how they're represented in HTML. I'd only replicate HTML conventions if I were using them across my entire design. I have no idea why the sale element has an expiration attribute.

4. Speaking of that sale element, represent boolean values using the strings true and false. (You can also use 1 and 0.) The broader point is: use XML Schema's representations for typed data.

Consistency in XML design is 100 times more valuable than readability. If you have consistent XML, you can trivially transform it into readable forms; the reverse is not the case.