tags:

views:

120

answers:

1

I'm trying to create an XML schema to describe some aspects of hospitals. A hospital may have 24 hour coverage on: emergency services, operating room, pharmacist, etc. The entire list is relatively short - around 10. The coverage may be on more than one of these services.

My question is how best to represent this. I'm thinking along the lines of:

<coverage>
    <emergencyServices/>
    <operatingRoom/>
</coverage>

Basically, the services are optional and, if they exist, the coverage is offered by the hospital.

Alternatively, I could have:

<coverage>
    <emergencyServices>true</emergencyServices>
    <operatingRoom>true</operatingRoom>
    <pharmacist>false</pharmacist>
</coverage>

In this case, I require all the elements, but a value of false means that the coverage isn't offered.

There are probably other approaches.

What's the best practice for something like this? And, if I use the first option, what type should the elements be in the schema?

+1  A: 

Best practice here depends really on the consumer.

The short and simple rule is that markup is for structure, and content is for data. So having them contain xs:boolean values is generally the best course.

Now, on to the options:

  1. Having separate untyped elements is simple and clear; sometimes processing systems may have difficulty reading them, because some XML-relational mappers may not see any data in the elements to put in relational tables. But if they had values, like <emergencyServices>true</emergencyServices>, then the relational table would have a value to hold.

  2. Again, if you have fixed element names, it means if your consumer is using a system that maps the XML to a database, every time you add a service, a schema change will have to be made.

    There are several other ways; each has trade-offs:

  3. Using a <xs:string> with an enumeration, and allow multiple copies. Then you could have <coverage>emergencyServices</coverage><coverage>operatingRoom</coverage>. It makes adding to the list simpler, but allows duplicates. This scheme does not require schema changes in the database for the consumer.

  4. You could use attributes on the <coverage> element. They would have a xs:boolean type, but still require a schema change. Of course, this evokes the attribute vs. element argument.

One good resource is Chapter 11 of Effective XML. At least this should be read before making a final decision.

lavinio