OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [regrep] Minutes of today's meeting


Title: RE: [regrep] Minutes of today's meeting
<Joe>
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.
</Joe>
 
I was not going that far, but it is an interesting scenario. I just think it might be beneficial if we can use "standard" (whatever that means) Core Components that are already defined.
 
<Joe>
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).
</Joe>
 
Yes, you are right. However, that is the same as with any other standard. And that is why our TC is careful and tries to produce specs that are backward compatible.
 
<Joe>
As we know, this type of thing is much better enforced with schemas. :)
</Joe>
 
When I say <to reuse available component validation and other routines / services for that component /> I am thinking beyond what XML Schema processor can offer.
 
Nikola
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC