I know that I owe you, my faithful readers (which BTW my last reports tells me that in total are...hum...zero), a couple of posts since August. I promise that I'll try to keep you (I mean...no one) updated with my recent thoughts :)
Back to the real post...
Yesterday, in one of our clients, we found out a real nice and tricky bug. In the BizTalk solution we have a message schema that looks something like this:
It's typical to insert a validation rule in the email. So, the Email field should look something like this:
In case you're wondering, this is done by setting the Base Data Type property with xs:string, setting the Data Type property with "Email" (just write it out) and paste "\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*" (without the ") into the Pattern property.
Now let's generate an instance of this schema. One example that's complaint with this schema could be:
<ns0:Person xmlns:ns0="http://TestingEmailAddressFormat.Message">
<Name>John Doe</Name>
<Address>Lisbon street, 1</Address>
<Phone>555-5555</Phone>
<Email>johndoe@somewhere.com</Email>
</ns0:Person>
If you validate this XML against our schema you'll get the message "Validate Instance succeeded for schema Person.xsd...". Perfect!
But let's perform a small change in Email field:
<ns0:Person xmlns:ns0="http://TestingEmailAddressFormat.Message">
<Name>John Doe</Name>
<Address>Lisbon street, 1</Address>
<Phone>555-5555</Phone>
<Email>john_doe@somewhere.com</Email>
</ns0:Person>
Validating this won't get us that nice message of success. Instead we get something like "error BEC2004: The 'Email' element is invalid - The value 'john_doe@somewhere.com' is invalid according to its datatype 'http://TestingEmailAddressFormat.Message:Email' - The Pattern constraint failed". That's a little awkward, because we were sure that our regex expression was right.
After some googling, Bruno found the reason for this error. It seems that in the .NET framework the "\w" option is equivalent to [a-zA-Z_0-9]. As you can see, it includes the "_" (underscore). But in the XSD schemas, the "\w" option doesn't include the "_"(underscore).
Bottom line, we had to change our validation regex expression for the Email field to "[A-Za-z0-9_]+([-+.'][A-Za-z0-9_]+)*@[A-Za-z0-9_]+([-.][A-Za-z0-9_]+)*\.[A-Za-z0-9_]+([-.][A-Za-z0-9_]+)*" (without the ").
Until next time ;)