In Brazil, the postal address consists of the name of the road, number of the house, name of the city (municipal), name of the barrio (suburb), and an unique CEP number unique to the street (only for urban streets). Rural addresses often have a reference of the kilometer mark on the road together with s/n (sem numero / without number). How can such an address be fitted into this proposal? I would suggest to tag all the CEP number in highway with cep=*. --Skippern 19:54, 25 February 2009 (UTC)
The proposed relations are too complicated in various respects. First of all, I find the a1..a6 elements counter-intuitive. Nobody can memorize their meanings, and people will mix them up all the time. Abbreviations like "hno" are far from obvious too. RFC 4119 may be fine for automated data transmissions, but in OSM we have plenty of human interaction with raw data. Remember that most mappers enter the tags manually.
Relations should include visible members (such as areas) if possible. Relations without visible members are difficult to work with. They are not locatable, and editors do not download them with an area.
A hierarchy of relations containing only other relations as members is even more difficult to maintain. You cannot get them displayed visually. You need to fiddle with lists and IDs. Mistakes are likely, and they will remain unnoticed forever.
The Munich University example comes with 6 (!!) relations. If every building needs that many relations, there will be an overflow in the editor's relation list. Or at least you will be overwhelmed by the number of relations. You could as well use one relation for each address, using addr:* tags instead of member names. Alternately, you can set addr:* and addr1:* tags on the building directly, needing no relation at all.
I think that address tags (postcode=*, addr:*, addr1:*, addr2:* etc.) on features and boundary relations are sufficient and far more maintainable than the relations proposed here. --Fkv (talk) 11:33, 5 January 2015 (UTC)