Table of Contents

Date

21 Sep 2017

Actions items from previous meetings

• Johan Sandersson: initiate vote to approve org.symphonyoss.fin.ccy.id.iso4217 [A] as a standard object.
• Former user (Deleted): work internally in IHSM to add CDS object(s) to working drafts and move the CDS Use Cases toward standardization.
• Jeff Sternberg (Deactivated) add open issues to subpage of Contact object working drafts page.
• Johan Sandersson reach out to Dov Katz about participating in Contact object discussion.
• Johan Sandersson initiate 2-week countdown to currency object vote.
• Former user (Deleted) review currency object with subject matter experts from IHSM currency trading group and notify WG of feedback.

Agenda

Action items

• Former user (Deleted) post input on currency object from IHSM currency subject matter experts.
• Bruce Skingle update drafts of number, string, and time.millis.

Meeting notes

Johan Sandersson: Any update Frank on rustling up contributors to the CDS object?

Bruce Skingle: What we discussed last week was getting someone from the currency trading space to look at the proposal. I don’t know if he did that, but he did vote for the proposal.

Frank Tarsillo: We did have some SMEs review that and there was a lot of good feedback, an hour and a half conversation about how the world uses currency identifiers, and important caveats, but I’ll make sure he gets us an update based on that conversations.

Johan Sandersson: Jeff, creating open issues for the contact object?

Jeff Sternberg: Yeah, there’s a discussion page and there’s been some conversation there.

Johan Sandersson: I reached out to Dov to get MS in to the working group, and they were interested, but they don’t seem to be able to make it today.

And the two-week countdown on the vote is done. So almost all our action items are done. Which brings us to the item I added to the agenda. I took out some of the definitions for “core objects” because I think those are going to be used in many of the objects, including contact and RFQ, so I thought it made sense to decide on those and push them up to the level of published standards. Then we can confidently reuse them. Bruce, Paul, and everyone, you’re probably more technical than me. Are there concerns, if we start with “number” – Bruce you recommended using subtypes instead of the arbitrary number.

Bruce Skingle: Yes, it’s obviously sensible to say that if we’re defining an object, if we can define it to be a long or a short instead of a number, that’s better. I’d say we put all the existing objects to a vote. Time (millis), definitely we should move ahead. I know there’s been discussion of alternative representations of time. I don’t have any problem approving other formats, but we absolutely need this one, as it’s the preferred format for most applications. The only reason moment becomes a thing is when you’re dealing with a range – we could include that, but I think we should just include uncontroversial ones at first—time.millis, string, and number—and we could treat the less basic ones separately.

Johan Sandersson: Do we need all these types in number?

Bruce Skingle: Well, if you’re dealing with node, the representation of a number won’t be any of those other types, so you’d want a generic number—a real or unbounded integral type—and then number on top of that. Does that make sense?

Johan Sandersson: Not to me!

Bruce Skingle: If you represent numbers in a way that it could be an unbounded number, then if we don’t provide the number type, there’d be no way of representing that in an unstructured object, which would be unfortunate.

Frank Tarsillo: It could be additive, so we can always go back and add further types.

Peter Monks: I think we need to take the Johan SanderssonON spec into account, because it has some unusual aspects that might require representation of larger types.

Bruce Skingle: Good catch. So we’d need to represent those larger types as a string within number.

Peter Monks: I think that’s right, with some out-of-band info on top.

Bruce Skingle: We’ll have to think it through but I don’t think we have to decide it to get this approved.

Peter Monks: The way another group I was in addressed it was an abstracted main model that didn’t deal with representation, and then separate documents mapped that to XML and Johan SanderssonON. We could consider something similar.

Bruce Skingle: But this is defined as Johan SanderssonON.

Peter Monks: But I still think it’s useful to have an abstract type so that the specific requirements of Johan SanderssonON don’t confuse or cloud the main object.

Bruce Skingle: There you go, Johan, it’s more complicated than we thought.

Johan Sandersson: So I proposed we move string and time.millis over to proposed standard…

Bruce Skingle: Hold on, the problem Peter’s describing isn’t limited to floating point numbers, so actually I don’t think we can just shift long and time.millis into proposed standards. Let me give it some thought and update the drafts, then we can look at it again before we go forward with a vote. I can turn that around in a couple of days. Then we can put these basic types to a vote as a bundle.

Johan Sandersson: Let’s look at the other items in working drafts. Jeff, do you want to talk about contacts and the discussion around that?

Jeff Sternberg: Yeah, it sort of relates to the time/core objects. With contacts, you don’t usually have precision. No one cares much about precision for start and end dates. So I feel like we need time components and the start/end properties of the contact object can use those.

Bruce Skingle: My proposal was that the date should be stored as milliseconds but that we should make additional definitions for time represented that way but are forced to meet a particular representations. So time.millis.day() should be “5” or whatever, but any finer resolution must be “0”. So you’d store the start day as midnight UTC on that day, and any other digits after “day” should be set to zero if they’re not. The advantage being that you’ll have less trouble with localization.

Peter Monks: We have two time use cases—an instant that doesn’t care about source time zone. Let’s move ahead with that one. Then there are “political” times that do care about source time zone, we should punt that, but Jeff should decide which he has on his hands with contact.

Johan Sandersson: Anything else, Jeff?

Jeff Sternberg: There’s this roles/titles standardization question. I think I just sort of took that out in the example document, but it may be worth touching on.

Paul Teyssier: There are multiple use cases where a standardized title/hierarchy would be useful, e.g. in a sales workflow. Another, perhaps more valuable, is role type: buy side, sell side, regulated, research, etc. The rules about whether you can use an app may be determined by this. We had multiple conversations about this in Symphony LLC with various stakeholders. And we decided that while it’s a worthy goal, it’s too complicated to block on it for right now. So we think roles should be just a string and the interpretation of its significance should be decided by whoever’s reading it.

Bruce Skingle: I think it’s a separate domain. If anyone’s interested in looking at this, you could look at the NATO rank standard, because it solves a similar but simpler problem.

Jeff Sternberg: The field I have is title. Should we have another for “role”?

Paul Teyssier: Well, there’s role, title, and rank. But for now I’d keep it simple and just define title.

Bruce Skingle: We could consider corporate title and functional title. Corporate being “VP” and functional describing what you actually do.

Jeff Sternberg: We call corporate title “corporate grade,” which is similar to rank.

Paul Teyssier: I’d avoid that and just stick with title for now.

Jeff Sternberg: I’m cool with that. The other question is about the contact.info object, which would encapsulate phone numbers, addresses, etc.

Bruce Skingle: Why not just put those right into the object? This isn’t a data model, so there’s no advantage to normalizing.

Jeff Sternberg: I was thinking of the situation where you have multiple addresses, etc.

Bruce Skingle: So if I give you Paul’s record, me telling you the ID of his record in my system is only useful if you’ve identified him the same way. And if you want to share a contact with someone else who uses your CRM, that’s captured by sharing the ID in that system.

Jeff Sternberg: I understand that, but I think it’s still useful to have multiple addresses or phone numbers per contact.

Bruce Skingle: But I think you need an additional field representing the instance of the system, unless that’s a globally unique ID, which I can’t imagine it is.

Jeff Sternberg: What I’m concerned with is passing along all of the contact details within a single object.

Bruce Skingle: If that’s what you’re doing, you don’t need the ID. I suggest we write down a user story so we can capture what’s actually needed here.

Peter Monks: Johan SanderssonON also allows people to jam in other attributes, so Ipreo could stick in its own attributes for consumption by its system that others would ignore.

Bruce Skingle: The only problem is the receiver won’t know what to do with it. Defining the semantics of the message is valuable so that, for example, non-Ipreo users can include information that’s useful to Ipreo users.

Attendees