tags:

views:

85

answers:

4

Without going into too much detail we are looking to use XML as meta-data to describe constraints on properties (This is a cutdown example and XSD did not support our proposed complex model), there are two options being considered, which of the following XML strucutures makes better sense?

Option 1)

<?xml version="1.0" encoding="us-ascii"?>
<Properties xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
   <Property type="string">
      <name>quanitity</name>
      <contraints>
         <contraint type="isRequired">
            <value>true</value>
         </contraint>
         <contraint type="regex">
            <value>^[0-9]$</value>
         </contraint>
         <contraint type="regex">
            <value>^[a-zA-Z]$</value>
         </contraint>
      </contraints>
   </Property>
</Properties>

Option 2)

<?xml version="1.0" encoding="us-ascii"?>
<Properties xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
   <Property type="string">
      <name>quantity</name>
      <IsRequired>true</IsRequired>
      <Regex>^[0-9]$</Regex>
      <Regex>^[a-zA-Z]$</Regex>
   </Property>
</Properties>
+1  A: 

For flexibility, I would go with #1. This will allow you to add many different types of constraints and custom rules.

Cody C
you don't really need the "value" tags. But having the containing element declare the type does allow for a better "OO" feel of the XML
Matthew Whited
Not to mention you can add more later without redefining the layout of your XML to add new child elements
Matthew Scharley
I actually view this as a disadvantage - It means you could easily pass in new constraint values that would pass XML validation but cause your parser code to blow up.
Adamski
Like most everything, there are always pro's and con's. #1 is more extensible, #2 is more rigid, but more checkable at compile-time. Which is more important really depends on the project.
Matthew Scharley
A: 

Personally, I'd go with the first one, I suspect it'd be easier to write code to parse and do error checking in. Plus it makes more sense semantically to my brain.

That said, I think you'll find it's 'personal choice', either is fine.

Matthew Scharley
+1  A: 

I would probably go for option #2 as the XML job does a better job of describing the data (which is after all what XML is supposed to do), and is therefore easier to read and less verbose. Option #1 is a little close to having <name> and <value> tags for my liking.

Adamski
+1  A: 

It depends on how you want to parse/process the XML and if you want to be able to validate it.

From a validation point of view (if you are considering automatic validation via an XSD at compile time) Option 2 is the better choice, as the content of the tags will have a certain type (e.g., a regular expression), while the <value> tag could not be checked for correct content.

Also, I would probably go with Option 2 concerning the parsing and processing if you are using a SAX parser, as you could switch states based on the tags.

Christian Hang
Of course it can be validated. It just takes a little more effort to figure out what rules to validate it against.
Matthew Scharley
For Option 1 you could not validate it with an XSD automatically, as there would be no way to figure out if the content of <value> should be a boolean, regex or something else based on the XML schema alone
Christian Hang