Have Geek Brain

Anyone ponder on my XML structure?

I'm relatively new to this, but I was hoping someone could offer a good critique of this XML structure I have put together. I'm not looking for anything in depth, but if someone notices something inherently wrong with the structure (or any advice to make it better), I would really appreciate it.

We have a large number of products that we sell in bulk and our customers were looking for a data feed to include our products on 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 package sizes hence the node.

+2


a source to share


3 answers


  • It is not clear to me that you are consistently using children to specify one-to-many relationships. If a product can have multiple categories, then it's okay, but if it can only have one, you're better off with single items named categoryName

    and categorySubcategory

    . Otherwise, someone somewhere will misunderstand the semantics of your XML, and you have a problem with a fix that would not have happened if you were consistent.

  • That being said, you need to have a plan in mind for what happens when you need to use multiple words in tag names.

  • It's not clear to me that you have a consistent reason to use attributes versus elements. I suspect you specified the image

    width

    and attributes height

    because they are represented in HTML. I would only replicate HTML conventions if I used them throughout my design. I have no idea why the element sale

    has an attribute expiration

    .

  • Speaking of this element sale

    , we represent boolean values ​​using strings true

    and false

    . (You can also use 1

    and 0

    .) Broader point: Use XML Schema views for typed data.



Consistency in XML design is 100 times more valuable than readability. Once you have consistent XML, you can trivially convert it to readable forms; the opposite is not true.

+1


a source


I think <pack>

u <price>

can be attributes <tier>

, or it is preferable to just remove <tier>

and have <pack>

u <price>

as attributes <pricing>

;

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

or



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

Not really sure if this makes sense for you (or your business), but will clean up the XML a bit.

0


a source


If you move all the attributes (ie The / modified

, width

, height

and expiration

) to an item, customers will automatically be able to match the specification of your product 1: 1 with JSON or internal object. In fact, one day you might consider providing JSON or protocol buffers as an alternate format for your data, and a simple XML structure will automatically transform. Relief if you have dozens of different XML formats (which may change from time to time). It is very rare for people to read XML and extract information from it manually, so there is no need to put the XML beauty first.

0


a source






More articles:


All Articles