Writing a book about a standard is different from implementing it. When you are implementing, you can get away with ignoring parts of the standard that aren't of concern to you. However, when writing a book about it, you need to cover details that wouldn't normally concern you, at least to explain to your audience why they do or don't matter, and when those rubriks apply. Somewhere in the middle of that is writing implementation guides. Because I'm now writing a book, I'm rereading the standard, and discovering things I didn't know. I'll be reporting these discoveries from time to time.
Over the weekend, I discovered something about addresses in CDA that I didn't previously know. Now I have an even deeper understanding (and perhaps some remaining confusion) about the AD data type.
There are about 27 different kinds of information that can appear in an address data type. They are all different kinds of address parts (ADXP) in the Version 3 Data Types standard. I knew that.
What I didn't know was the difference between <streetAddressLine> and <deliveryAddressLine>, and some fine details about the XML representation of these parts. You've probably never seen the <deliveryAddressLine> referenced in any implementation guide, but it should have been. The difference between a <streetAddressLine> and a <deliveryAddressLine> is the difference between a physical delivery address and a PO Box, rural route or other sort of delivery address. A dearth of examples probably contributes to my lack of knowledge.
The Version 3 data types standard (both release 1 and 2) represents the address data type (AD) as a list of Address parts (ADXP), which can repeat any number of times. Practically, some of these should only appear once (e.g., postal code, city, state, country or county), while others could appear multiple times (e.g., streetAddressLine or deliveryAddressLine). There is also hierarchy of address part types which seems to imply a whole/part relationship between elements of the hierarchy. For example, you would imagine that the <streetAddressLine> could contain a <streetName> element. However, the data types schema doesn't allow the content of a <streetAddressLine> to contain a <streetName> element. If you are going to parse any portion of the street address in detail, you cannot wrap the parsed elements in a <streetAddressLine> element.
The long and short of it is that I learned something new, and now, hopefully, you have too.
Hi Keith,
ReplyDeleteIt's my hope you won't focus on datatype issues in your book, with the exception of soe examples. Datatypes deserve a book of their own .. and to describe them in a truly universal fashion requires a lot of space and attention to detail.
That having been said, the AD data type is a very flexible one, to cater to all strange ways of addressing out there. And yes, this included the addresses of "Houseboats" in Amsterdam canals, campervans illegally parked somewhere, and cities that officially don't exist..
-Rene
hi Keith, Rene
ReplyDeleteSo, datatypes are actually going to get a book of their own. In the mean time, a comment about nesting part types: actually being able to nest would not have any practical outcome, since the nesting is implied by the structure of the vocabulary
Now I have a much deeper comprehension (and maybe some remaining perplexity) about the AD information sort.
ReplyDeleteThroughout the weekend, I uncovered something about locations in CDA that I didn't awhile ago know. Now I have a much deeper comprehending (and maybe some remaining disarray) about the AD information sort.
ReplyDeletedispensing system | colour kitchen | in can tinting