[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Minutes of today's meeting
A lot of interesting and out of the box thinking on this thread! May I suggest that the prudent thing architecturally is for us to not have any direct coupling between RIM classes and UBL/CC definitions. As Joe mentioned it brings up the issue of having to adapt to version changes of the UBL/CC definition. It would also require breaking backward compatibility (something we have managed to avoid in V3 proposals thus far). We can have the benefit of Nikola's original suggestion by simply doing due diligence at each release to make sure that we sync with any changes in the UBL/CC definitions and make equivalent RIM classes stay compatible. Anything beyond that would be questionable from an architectural standpoint. --
"CHIUSANO, Joseph" wrote: Ah, I see...so, for instance, if the UBL representation of Organization and the registry class for organization matched, the registry could potentially accept a UBL transaction containing Organization information as a means to create an instance of an Organization class within the registry, thereby alleviating the need for a user to enter this information. The same could apply for class PostalAddress, class PersonName, etc.I like this idea, but I would offer a caveat (as I mentioned in our call yesterday) that if the UBL representation of Organization were to change (for example, an element is no longer mandatory), the RIM class would need to be updated (which as we know would not be an easy change).As we know, this type of thing is much better enforced with schemas. :)Thanks,Joe************************************************************************** |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC