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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: [ubl-ndrsc] Reusability and Context


Greetings,

I'm probably just stating the obvious for the rest of you, but this little mental exercise helped me get a look at the big picture.

This represents my understanding of the slide Tim showed, at Friday's NDR/LCSC Joint Meeting, with an arrow from L-R indicating increased context, and an arrow from R-L indicating increased reusability:

On the far left would be the Basic Core Components with no business context (e.g. Street, ZIP_ Post Code and Town). These would be the most reusable components. To the right of that would be our BBIEs, where we have given a business context to the BCCs. These would be reusable within the business context we have supplied. (In general, we will find BIEs to the right of the Core Components from which they are derived.)

Further to the right would be our 'basic' ACCs, such as Address, which are composed solely of the BCCs defined on the far left. Now, our Street, ZIP_ Post Code and Town BCCs have a context. If someone wants to use Zip_Post Code in a context other than 'Address' they will have to 'move to the left' to do it. However, Address exists without any 'external' context (if that makes any sense) so it will be able to be reused in many situations.

Further to the right of Address would be our Party, which contains Address. Here Address has a context, but Party does not. So on and so forth...

As we move from left to right, the ACCs/ABIEs and ASCCs/ASBIEs are composed of those CCs/BIEs defined previously (to its left), thereby giving them context.

At the far right would be our 'documents' (Order, Invoice, etc.).

Now, if someone wants an Address that contains Party, they would not be able to use the 'existing' Address element; however, they could extend our Address type. 

I think that if one of our goals is to facilitate reuse of elements as well as types, then we should consider which permutations of our BIEs/ABIEs/ASBIEs we want to define as elements, without necessarily including them in one of our 'documents'. (If only xsd allowed us to indicate something like 'Party includes Address' xor 'Address includes Party' and things of that nature...)

Thank You,
Mike Grimley

GrimleyMJ@npt.nuwc.navy.mil


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


Powered by eList eXpress LLC