Do you think there is any need for a "list" tag type? Has there been any prior discussion on this point?

I think there might be instances where a specific tag could legitimately have multiple values that are not easily broken down into distinct tag/value pairs. For example,

buildingManagers: "John Doe", "Jane Doe"

Seems better than

buildingManager1: "John Doe"
buildingManager2: "Jane Doe"

A list type that could comprise other haystack values would be pretty powerful; especially if thy could be composed.

There are many times when I've been tempted to create such a beast. But I still sort of think the simplicity of having simple scalar types for tag values out weighs the flexibility + complexity of list values.

In some ways we are a bit more like IETF specs where we just encode stuff into a string. A good example is the enum tag. Some might say that is an absuse of strings, but I personally like that approach :-)

For more complicated modeling, I think we need to use a "join table" approach. For example there are cases where a VAV might be fed by multiple AHUs which discharge into shared duct work. In that case, we would have to create a "join" record like this:

id: @AHU-Group
ahuGroup

id: @AHU-1
ahuGroupRef: @AHU-Group

id: @AHU-2
ahuGroupRef: @AHU-Group

id: @VAV-x
ahuGroupRef: @AHU-Group

If we wanted a list, couldn't we just do this:

tagName:"one,two,three,four,five"

Keep is a string, and just add the list as the value?

Keep is a string, and just add the list as the value?

Yes that is what we do for the enum tag.

This certainly works:

tagName: "one,two,three,four,five"

But it is not self-describing in the same way that an actual type would be. Is it a Str that happens to look like a list? Or is it a list? It really is a Str, and now you have to have additional semantics that tell you what to do with it. You basically have to come up with your own little specification:

tagName is a Str that is parsed as a list of comma-separated values (so comma is not allowed in the list items). What about white-space? Is "one, two, three" the same as "one,two,three"?

A list type would remove all these concerns, plus your list items would be typed.

tagName: ["one", 2ft, `http://project-haystack.org`]

I definitely see that it complicates haystack some to introduce the list type, but I think there are downsides to string parsing approach as well.

I agree with Matt all the way. Why can't we do this Brian, I really think we need it.

I really think we need it.

Why do you think we need it? I don't think we have had a single use case for something like this yet. And that is after 3 years of modeling a lot of different stuff. I think we have had one case in SkySpark we wanted to store a list of Refs. The only potential use case for a standard tag so far has been enum - but that is a red herring - it should just be comma separated Str.

So the upside seems quite fuzzy IMO. On the other hand, what is the downside? The downside is a massive increase in complexity. We move from a simple model based on name/scalar values pairs to something that now has to deal with nested data structures. Every serialization format has be enhanced to deal with it. You can't easily map grids to a spreadsheet or CSV. It would also become impossible to map tags to a row in a RDBMS and essentially the indeed the nice relational properties we have are thrown out the window. If you did want to keep any of those spreadsheet or relational properties then you would have to figure out how to encode the list using a string, in which case what do we really buy?

One very concrete use case I do have right now is how to model a lat/lon coordinate in an "atomic" or "scalar" way. This sort of data is actually critical to many domains (not BAS, but any sort of mobile system). Some core list type might be a solution to that, but I've actually been thinking coordinates should be a core type like Number+unit.

I think there are tons of examples on why you might want to have a list. I even think you would want the recID to be able to except a list.

1. What if 1 piece of Equipment was a subSystem of two different equipments. IE... A Vav that was served by Multiple AHUs, or a Central Plant that serves multiple Sites/Buildings.

I think the problem can be solved by using a string, and just putting the list in the string, but like Matthew said, programmatic we don't know that is actually a list. If we knew it was a list it would make things much easier.

I also agree with you that once you have a list, it's makes the UI/Grid harder to understand, but since we already have to do this with a sting, what's the difference? Why not just have this as an option too?

I think there are tons of examples on why you might want to have a list. I even think you would want the recID to be able to except a list.

If we are discussing specifically a new scalar type to store a list of Refs, then yeah I think we'll end up wanting this. But that is a very different proposition than a generic list usable anywhere a scalar type is accepted (which would imply support for lists of lists).

In a relational database, every cell in your tables store scalar values just like Haystack (pretty much using same type system). When you want to store lists, you create multiple rows and/or join tables. This is the approach I've been thinking we should use for many-to-many relationships - its a pretty standard way to map entity models. But I could potentially see using a list of Refs instead. But on the other hand, I can also see it adding a lot of complexity to all the APIs I've done with Java, Fantom, Axon.

Its a big decision, so one hand it seems like we should really take our time to consider something of this magnitude. But on the other, now would be a great time to add it because we are process of locking a lot of this stuff down.