Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

preamble

On this page we, (Paul, Val, Sam) discuss the form of the address change messages.

The latest proposed revision is "example 11".
This is mostly implemented with a few minor changes proposed (follow links - see TODOs).
Here is a sample xml file.

questions/answers

Q1
From DBI's perspective, we are either going to be inserting addresses or updating addresses with your data. (Addresses are never deleted but retired on our end and yours I believe). How will we tell the difference if it is an address update or a brand new address? via an XML tag?

...

A5
I will add the native primary key to the messages.

[Sam] Can you be more specific here? My understanding is that in the MAD data model, both the base address and unit address tables have "native primary keys". If that's correct, then A5 is ambiguous.

Q6
DBI does not track addresses with no ownership but MAD does.
For example, an apartment build with 10 aprtments will have 10 MAD addresses but only 1 DBI address.
HOw will we handle this?

...

Q8
Val,
As of july 28 2010, the EAS will publish address changes like this.

A8

...

A simple example to get us started.
This example is MAD centric.
I suspect that we'll end up with something a alot different at the end of this discussion.
Here is a single family dwelling with one owner:

...

I originally agreed to this because this is easier for AVS consumer.
I'd like to discuss doing it this way.
Here's why. Say that during the xmit the power goes out.
When we come back up, the daemon will retransmit some or all of the messages.
This is because of the transaction scope, which in EAS is naturally at the unit address level.
I'd like to avoid sending out duplicates if at all possible.
Now, if necessary, I can add some extra code (and a table) to handle this completely on my end.
But I'd like to get your feedback.

A8
The final form is here.

Example 1
Anchor
example1
example1

A simple example to get us started.
This example is MAD centric.
I suspect that we'll end up with something a alot different at the end of this discussion.
Here is a single family dwelling with one owner:

Code Block
    <address>
        <number>14</number>
        <street>MAPLE ST</street>
        <unit>
              <base>true</base>   <base>true</base>
            <number></number>
            <disposition>official</disposition>
            <create_tms>2010-07-02 08:18:50.937000</create_tms>
            <retire_tms>None</retire_tms>
            <apns>
                <apn>1234001</apn>
            </apns>
            <action>insert</action>
        </unit>
    </address>

The "action" tag domain is

Code Block
    insert
    update
    retire

I think this addresses question 1 above.

The "base" tag domain is:

Code Block
    true
    false

This is a MAD artifact - DBI probably won't want it.
But let me explain the purpose.
A MAD "address" is represented using the concept of a base address and a unit address.
A base address always has one corresponding unit address.
There may be additional unit addresses or not.
If the base tag is marked true, then this unit information is directly associated with the base address.
If the base tag is marked false, then this unit information is not directly associated with the base address.

[Sam] Can you elaborate on what is meant by "directly associated" in this context? Are there additional associations possible between a unit address and a base address (besides "not direct")?

Example 2
Anchor
example2
example2

Now in the case of an apartment bldg, say
14 MAPLE ST,
apartments a & b
MAD represents the world this way:

Code Block
    <address>
        <number>14</number>
        <street>MAPLE ST</street>
        <unit>
            <base>true</base>
            <number>100</number>
            ...
            <apns>
                <apn>1234001</apn>
            </apns>
            <action>insert</action>
        </unit>
        <unit>
            <base>false</base>
            <number>a</number>
            ...
            <apns></apns>
            <action>insert</action>
        </unit>
        <unit>
            <base>false</base>
            <number>b</number>
            ...
            <apns></apns>
            <action>insert</action>
        </unit>
    </address>

There is no ownership at the unit level.
The owner is specified at the base address level.

Example 3
Anchor
example3
example3

What I think we want an instead of the example 2 (apt building) is something like this:

message 1

Code Block
<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>
        <address>
            <number>14</number>
            <street>MAPLE ST</street>
            <unit_number>100</unit_number>
            <block>1234</block>
            <lot>001</lot>
            <apn>1234001</apn>
        </address>
    </address_change>
</xml>

Example 4
Anchor
example4
example4

And reworking example 1 (single family) to fit the model shown in example 3, we have this:

Code Block
<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>
        <address>
            <number>14</number>
            <street>MAPLE ST</street>
            <unit_number></unit_number>
            ...
            <block>1234</block>
            <lot>001</lot>
            <apn>1234001</apn>
        </address>
    </address_change>
</xml>

Example 5
Anchor
example5
example5

Let's move on to a time share, which can be seen at 2655 Hyde St.
In a time share we have a single unit with multiple owners.

message 1

Code Block
<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>
        <address>
            <number>2655</number>
            <street>HYDE ST</street>
            <unit_number>1</unit_number>
            <disposition>provisional</disposition>
            <create_tms>2010-07-02 14:11:22.843000</create_tms>
            <retire_tms>None</retire_tms>
            <block>0026T</block>
            <lot>065A</lot>
            <apn>0026T065A</apn>
        </address>
    </address_change>
</xml>

message 2

Code Block
<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>
        <address>
            <number>2655</number>
            <street>HYDE ST</street>
            <unit_number>1</unit_number>
            <disposition>provisional</disposition>
            <create_tms>2010-07-02 14:11:22.843000</create_tms>
            <retire_tms>None</retire_tms>
            <block>0026T</block>
            <lot>066A</lot>
            <apn>0026T066A</apn>
        </address>
    </address_change>
</xml>

The only difference here is that the APN is different in message 2.
This much is straight forward.
If a unit address changes, and there are APNs assigned to the unit,
we have one address change message for each of these APNs.
But at 2655 Hyde, there are lots of APNs assigned to the base address.

Anchor
apn_question2
apn_question2

Val, please take a look at this address and tell me if you think we need to
do anything special here.
http://174.37.80.164/

Example 6
Anchor
example6
example6

Here is a condo or tenants in common example, where each unit has a single owner, and there
is a "common area" owned by the owners association.

message 1 (base unit or common area, APN is assigned)

Code Block
<xml>
    <address_change>
        <key>12873</key>
   <number></number>     <action>insert</action>
       <disposition>official</disposition> <address>
           <create_tms>2010-07-02 08:18:50.937000</create_tms> <number>100</number>
            <street>MAIN <retire_tms>None</retire_tms>ST</street>
            <apns><unit_number></unit_number>
                <apn>1234001</apn>
   <disposition>provisional</disposition>
        </apns>    <create_tms>2010-07-02 14:11:22.843000</create_tms>
       <action>insert</action>     <retire_tms>None</retire_tms>
   </unit>     </address> 

The "action" tag domain is

Code Block
   <block>1234</block>
 insert     update     retire

I think this addresses question 1 above.

The "base" tag domain is:

Code Block
 <lot>001</lot>
      true     false

This is a MAD artifact - DBI probably won't want it.
But let me explain the purpose.
A MAD "address" is represented using the concept of a base address and a unit address.
A base address always has one corresponding unit address.
There may be additional unit addresses or not.
If the base tag is marked true, then this unit information is directly associated with the base address.
If the base tag is marked false, then this unit information is not directly associated with the base address.

...

Now in the case of an apartment bldg, say
14 MAPLE ST,
apartments a & b
MAD represents the world this way:

Code Block

    <address>
 <apn>1234001</apn>
        </address>
    </address_change>
</xml>

message 2 (condo unit)

Code Block
<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>
        <address>
            <number>100</number>
            <street>MAIN ST</street>
       <number>14</number>     <unit_number>1</unit_number>
            <disposition>provisional</disposition>
   <street>MAPLE ST</street>         <unit><create_tms>2010-07-02 14:11:22.843000</create_tms>
            <base>true</base><retire_tms>None</retire_tms>
            <number>100<<block>1234</number>block>
            ...<lot>002</lot>
            <apns><apn>1234002</apn>
        </address>
    </address_change>
  <apn>1234001</apn></xml>

message 3 (condo unit)

Code Block
<xml>
    <address_change>
       < <key>12873</apns>key>
        <action>insert</action>
    <action>insert</action>    <address>
    </unit>        <number>100</number>
<unit>            <street>MAIN <base>false<ST</base>street>
            <number>a<<unit_number>2</unit_number>
            ...<disposition>provisional</disposition>
             <apns></apns><create_tms>2010-07-02 14:11:22.843000</create_tms>
            <action>insert</action>
<retire_tms>None</retire_tms>
       </unit>     <block>1234</block>
   <unit>         <lot>003</lot>
   <base>false</base>         <apn>1234003</apn>
   <number>b</number>     </address>
    </address_change>
<xml>
 ...

Example 7
Anchor
example7
example7

Code Block
    <address>
         <apns><<key>419692</apns>key>
        <base_number_prefix></base_number_prefix>
   <action>insert</action>      <base_number>1</base_number>
  </unit>     </address>

There is no ownership at the unit level.
The owner is specified at the base address level.

...

What I think we want an instead of the example 2 (apt building) is something like this:

message 1

Code Block

<xml>
    <address_change> <base_number_suffix></base_number_suffix>
        <street_name>S VAN  <key>12873</key>NESS</street_name>
        <action>insert</action><street_name_suffix>AVE</street_name_suffix>
        <address><unit_number_prefix></unit_number_prefix>
        <unit_number>600</unit_number>
   <number>14</number>       <unit_number_suffix></unit_number_suffix>
     <street>MAPLE ST</street>  <create_tms>2010-08-03 12:05:54.578000</create_tms>
         <unit_number>100</unit_number><retire_tms>2010-08-03 12:38:33</retire_tms>
        <disposition>provisional</disposition>
    <block>1234</block>    <mailing>True</mailing>
        <lot>001</lot><longitude>-122.418862841</longitude>
            <apn>1234001</apn>
 <latitude>37.7747051425</latitude>
      </address>     </address_change>
</xml>

...

And reworking example 1 (single family) to fit the model shown in example 3, we have this:

Code Block

<xml><change_tms>2010-08-03 14:38:33.467492</change_tms>
        <address_change><action>retire</action>
        <key>12873<<block>3506</key>block>
        <action>insert<<lot>001</action>lot>
        <address><apn>3506001</apn>
    </address>

Example 8
Anchor
example8
example8

Code Block
<addresses>
    <address>
 <number>14</number>       <key>419623</key>
     <street>MAPLE ST</street>  <base_number_prefix></base_number_prefix>
          <unit<base_number><number>2655</unitbase_number>
        <base_number_suffix></base_number_suffix>
     ...   <street_name>HYDE</street_name>
         <block>1234</block><street_name_suffix>ST</street_name_suffix>
        <unit_number_prefix></unit_number_prefix>
    <lot>001</lot>    <unit_number>308</unit_number>
        <apn>1234001</apn><unit_number_suffix></unit_number_suffix>
        <<disposition>provisional</address>
    </address_change>
</xml>

...

Let's move on to a time share, which can be seen at 2655 Hyde St.
In a time share we have a single unit with multiple owners.

message 1

Code Block

<xml>disposition>
         <address_change><create_tms>2010-07-02 14:11:22.843000</create_tms>
        <key>12873</key><retire_tms></retire_tms>
        <action>insert<<block>0026</action>block>
        <address><lot>028</lot>
            <number>2655</number><apn>0026028</apn>
    </address>
       <street>HYDE ST</street>
            <unit_number>1</unit_number>...
</addresses>

Example 9
Anchor
example9
example9

This separates the "history" information,

Code Block
<addressChangeNotification>
    <address>
        <disposition>provisional<<key>419709</disposition>key>
            <create_tms>2010-07-02 14:11:22.843000</create_tms><base_number_prefix></base_number_prefix>
            <retire_tms>None</retire_tms><base_number>1</base_number>
            <block>0026T</block><base_number_suffix></base_number_suffix>
            <lot>065A</lot><longitude>-122.418876252</longitude>
            <apn>0026T065A</apn><latitude>37.774694542</latitude>
        </address>
    </address_change>
</xml>

message 2

Code Block

<xml><street_name>S VAN NESS</street_name>
        <address_change><street_name_suffix>AVE</street_name_suffix>
        <key>12873</key><unit_number_prefix>XXX</unit_number_prefix>
        <action>insert</action><unit_number>300</unit_number>
        <address><unit_number_suffix>YYY</unit_number_suffix>
            <number>2655</number><create_tms>2010-08-13 12:15:43.828000</create_tms>
            <street>HYDE ST</street>
<retire_tms>2010-08-13 18:41:16.149255</retire_tms>
           <unit_number>1</unit_number><disposition>provisional</disposition>
        <mailing>True</mailing>
   <disposition>provisional</disposition>     <block>3506</block>
       <create_tms>2010-07-02 14:11:22.843000</create_tms> <lot>001</lot>
        <apn>3506001</apn>
    <retire_tms>None</retire_tms></address>
       <timestamp>2010-08-13 18:41:16.149255</timestamp>
    <block>0026T<<action>retire</block>action>
</addressChangeNotification>

Example 10
Anchor
example10xml
example10xml

DBI may use different street names and street suffixes.
This version accommodates these variations.

Code Block
<addressChangeNotification>
    <address>
     <lot>066A</lot>   <key>419709</key>
         <apn>0026T066A</apn><base_number_prefix></base_number_prefix>
        </address><base_number>1</base_number>
    </address_change>
</xml>

...

Here is a condo or tenants in common example, where each unit has a single owner, and there
is a "common area" owned by the owners association.

message 1 (base unit or common area, APN is assigned)

Code Block

<xml>
    <address_change>    <base_number_suffix></base_number_suffix>
        <jurisdiction>PRESIDIO</jurisdiction>
        <longitude>-122.418876252</longitude>
        <latitude>37.774694542</latitude>
        <street_name>SOUTH VAN <key>12873<NESS</key>street_name>
        <action>insert</action><street_name_suffix>
            <address><abbreviated>AVE</abbreviated>
            <number>100<<unabbreviated>AVENUE</number>unabbreviated>
        </street_name_suffix>
   <street>MAIN ST</street>    <unit_number_prefix>XXX</unit_number_prefix>
        <unit_number><number>300</unit_number>
 number>
          <disposition>provisional</disposition>
 <unit_number_suffix>YYY</unit_number_suffix>
          <create_tms>2010-0708-0213 1412:1115:2243.843000<828000</create_tms>
   
        <retire_tms>None<tms>2010-08-13 18:41:16.149255</retire_tms>
        <disposition>provisional</disposition>
   <block>1234</block>     <mailing>True</mailing>
        <lot>001<<block>3506</lot>block>
            <apn>1234001</apn><lot>001</lot>
        <<apn>3506001</address>apn>
    </address_change>
</xml>

message 2 (condo unit)

Code Block

<xml>
    <address_change>
        <key>12873</key>
        <action>insert</action>address>
    <timestamp>2010-08-13 18:41:16.149255</timestamp>
    <action>retire</action>
</addressChangeNotification>

Example 11
Anchor
example11xml
example11xml

The purpose of this version is to support the rework of the model precipitated by MAD-156.

Code Block
<?xml version="1.0" encoding="utf-8"?>
<addressChangeNotification>
    <base_address_part>
        <address><base_address>
            <number>100</number>
            <street>MAIN ST</street><base_address_id>483699</base_address_id>
            <unit<base_number_number>1<prefix></unitbase_number_number>prefix>
            <disposition>provisional</disposition><base_number>2569</base_number>
            <create_tms>2010-07-02 14:11:22.843000</create_tms><base_number_suffix></base_number_suffix>
            <jurisdiction>SF <retire_tms>None</retire_tms>MAIN</jurisdiction>
            <block>1234</block><longitude>-122.387658226</longitude>
            <lot>002<<latitude>37.756713011</lot>latitude>
            <apn>1234002</apn><street_name>03RD</street_name>
        </address>     </address_change>
</xml>

message 3 (condo unit)

Code Block

<xml><street_name_suffix>
       <address_change>         <key>12873<<abbreviated>ST</key>abbreviated>
        <action>insert</action>        <unabbreviated>STREET</unabbreviated>
<address>             <number>100</number></street_name_suffix>
            <street>MAIN ST</street></base_address>
        <action>insert</action>
    <unit_number>2</unit_number></base_address_part>
    <unit_address_part>
       <disposition>provisional</disposition> <unit_address>
            <create_tms>2010-07-02 14:11:22.843000</create_tms><address_id>725579</address_id>
            <retire<unit_tms>None<number></retireunit_tms>number>
            <block>1234</block><base_unit_address_flag>True</base_unit_address_flag>
            <lot>003<<disposition>official</lot>disposition>
            <apn>1234003<<mailing>False</apn>mailing>
        </address>     </address_change>
<xml>

...

Code Block

<address>
    <key>419623</key>
    <base_number_prefix></base_number_prefix><create_tms>10-16-2012 11:10:35</create_tms>
       <base_number>2655</base_number>     <base<last_number_suffix></base_number_suffix>
    <street_name>HYDE</street_name>change_tms>10-16-2012 11:10:35</last_change_tms>
       <street_name_suffix>ST</street_name_suffix>     <unit<retire_number_prefix><tms></unitretire_number_prefix>
    <unit_number>308</unit_number>tms>
        <unit_number_suffix><</unit_number_suffix>address>
    <disposition>provisional</disposition>     <create_tms>2010-07-02 14:11:22.843000</create_tms><action>insert</action>
    <retire_tms></retire_tms></unit_address_part>
    <block>0026</block><address_parcel_link_part>
    <lot>028</lot>     <apn>0026028</apn>
</address>

...

Code Block

<addresses><address_parcel_link>
       <address>     <id>563590</id>
   <key>419623</key>         <base_number_prefix></base_number_prefix><create_tms>10-16-2012 11:10:35</create_tms>
            <base_number>2655</base_number>
 <last_change_tms>10-16-2012 11:10:35</last_change_tms>
      <base_number_suffix></base_number_suffix>      <retire_tms></retire_tms>
  <street_name>HYDE</street_name>         <street_name_suffix>ST</street_name_suffix>
 <parcel>
       <unit_number_prefix></unit_number_prefix>         <unit_number>308</unit_number>
<block>4173</block>
       <unit_number_suffix></unit_number_suffix>         <disposition>provisional<<lot>001</disposition>lot>
          <create_tms>2010-07-02 14:11:22.843000</create_tms>     <apn>4173001</apn>
   <retire_tms></retire_tms>         <block>0026<</block>parcel>
        <lot>028</lot></address_parcel_link>
        <apn>0026028<<action>insert</apn>action>
    </address>
    ...
</addresses>address_parcel_link_part>
</addressChangeNotification>