XML structure for a personal organizer

Question

I'm doing a personal organizer for learning purposes, and i've never worked with XML so i'm not sure if my solution is the best. Here's the basic structure for the XML file i came with:

<calendar>
    <year value="2008">
        <month value="october">
            <day value="16">
                <activity name="mike's birthday" time="21:00" address="mike's apartment" urgency="10">
                     activity description.
                </activity>
            </day>
        </month>
    </year>
</calendar>

The urgency attribute should be on a scale of 1 to 10.
I did a quick search on google and couldn't find a good example. Maybe that's not the best solution, and i'd like to know if its adequate. I'm doing the application in PHP if that has any relevance.

Answer 1

Your way is quite adequate to me. However, I prefer child tags to attributes, so my way would be more like:

<activity>
  <name>Mike's Birthday</name>
  <time>2100</time>
  <address>Mike's Place</address>
  <urgency>10</urgency>
  <description>activity description</description>
</activity>

But like I said, your way is just fine.

Quick question, though - why not a database?

Answer 2

You may have arrived at this naively, but the primary feature of your XML design is that it is optimized for searching by date. If your XML document is large, and you do a lot of searching by date (which I suspect is the most common use case in a personal organizer), this is a good thing.

Executing this XPath pattern:

/calendar/year[@value='2008']/month[@value='10']/day[@value='7']/activity

will examine many fewer nodes than will using the pattern you'd need to use with Kev's simpler flattened-out organization:

/calendar/activity[@year='2008' and @month='10' and @day='7']

which basically has to look at every node in the document.

Note, by the way, that I'm assuming that the month and day attributes are numeric. This is important because you'll almost certainly want to sort this data at some point, and unless you're going to maintain the sort order in the document (which, I'll admit, an argument can be made for), you'll want those attributes in a form that it's easy to sort them in.

It's also important that you're consistent in how you store numeric data in those attributes. (If you want to sound smart in meetings, you can say that you're establishing canonical representations of your data types.) If you use leading zeroes some times and not others, for instance, none of those XPath patterns will work reliably, because @day='7' won't match a day attribute set to "07". (You can get around that by converting the attributes to numbers in your XPath using the number() function, but avoiding the problem in the first place is better.)

Answer 3

You could flatten that hierarchy down to:

<calendar>
    <activity
        id="123456"
        name="mike's birthday" 
        year="2008"
        month="10"
        day="16"
        time="21:00" 
        address="mike's apartment" 
        urgency="10">
            activity description.
        </activity>
</calendar>

or..

<calendar>
    <activity id="12345">
        <name>mike's birthday</name>
        <year>2008</year>
        <month>10<month>
        <day>16</day>
        <time>21:00</time>
              <urgency>10</urgency>
        <address>mike's apartment<address>
        <description>activity description.</description>
    </activity>
</calendar>

It'd make life a bit less painful doing XPath queries. I also added an id attribute so you can uniquely identify an activity.

Answer 4

I think your structure will be fine for what you are doing.

If you're planning to use this partly to learn about XML, you might consider using a mix of attributes and elements so that you get practice working with collections of each. Once you're more comfortable with XML, you will probably start to define rules that you'll use to determine which properties become attributes and which properties become elements.

With the right code, you can move information back and forth between XML files and database tables. You could also start learning XSL so that you can practice moving things around without changing the original XML file (or, once the data is in a table, not even have an original XML file).

Answer 5

It might be worth looking at xCal, an XML-compliant representation of the iCalendar standard, for some potentially well-thought-out ideas.