Street address, given Names should be arrays not singletons about bluebutton.js

[blacktm]

Should bb.js flatten these to simple strings? @mjacksonw, is this useful to you?

[jmandel]

.join(" ") makes good sense for names. I'm not so sure about addresses (but it's a reasonable start).

[blacktm]

Agreed. Joining names is probably a good default. Addresses should probably be arrays – gives flexibility for formatting on the front end (comma delimited, new line for each entry, etc).

Quick question, I don't have an example with multiple address lines, but does it just look like this?

<addr use="HP">
  <streetAddressLine>17 Daws Rd.</streetAddressLine>
  <streetAddressLine>Apt 34534abc</streetAddressLine>
  <streetAddressLine>A Third Address Line</streetAddressLine>
  <city>Blue Bell</city>
  <state>MA</state>
  <postalCode>02368</postalCode>
  <country>US</country>
</addr>

[jmandel]

Yep, that's what I'd expect.

On Mon, Apr 8, 2013 at 5:55 PM, Tom Black [email protected] wrote:

Agreed. Joining names is probably a good default. Addresses should
probably be arrays – gives flexibility for formatting on the front end
(comma delimited, new line for each entry, etc).

Quick question, I don't have an example with multiple address lines, but
does it just look like this?

17 Daws Rd. Apt 34534abc A Third Address Line Blue Bell MA 02368 US

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-16088300
.

[mjacksonw]

If I'm understanding your question correctly, I think of flattening as being presentational, and I think of bb.js being at least a layer below that, focusing on the data (at least at this stage). There probably isn't tremendous need for front-enders to need a pre-flattened version of either at this layer, since it's so trivial to join them (or handle them in some other way) as needed.

For the tools I'm building, most folks will probably rely on the full_name and display_name filters I've built, that take a full name object and spit out reasonable representations for those respective needs, or they'll use the object directly to construct their own representations.

[blacktm]

Yep, I think we're all agreeing here. I'll stick to the native CCDA data representations (unless something is particularly ugly). @mjacksonw, If you'd like me to build in composite or "pre-processed" properties, like full_name or something, let me know. It's sort of in a gray area: a data thing vs. presentation. If it makes data access more convenient, might be worth considering building it into bb.js.

[mjacksonw]

The filters and sorting are way more important, imho. The whole point of my library is presentational, so I won't be making any real requests in that regard.

[blacktm]

Sounds good. Feel free to start opening issues around bb.js filters you might want.

BTW, this issue now resolved in latest build.