Title: RE: [regrep] Minutes of today's meeting
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
**************************************************************************
Joseph M. Chiusano
Logistics Management Institute
2000 Corporate Ridge
McLean, VA 22102
Email:
Tel: 571.633.7722
**************************************************************************
-----Original Message-----
From: Nikola
[mailto:]
Sent: Friday, August 09, 2002
9:37 AM
To: ebXML Regrep (E-mail)
Subject: Re: [regrep]
Minutes of today's meeting
<JoesAddition>
The specific
issue has to do with whether or not the registry should enforce compatibility
with various standards (UBL, etc.). Nikola described a scenario in which
the registry would verify that a certain component (e.g. Address) "conforms"
to a certain standard - e.g. the UBL version of Address.
</JoesAddition>
What I was trying to communicate was that Core
Components Review subcommittee should investigate whether our RIM classes,
like Organization ... could be compatible with CC, UBL ... and if yes, what
would be necessary to do. This would be a low priority item at this time. In
case that we can reuse some of these components, registry would be able to
reuse available component validation and other routines / services for that
component to process its own components.
Nikola