Re: [ubl-ndrsc] Reusability and Context

["Eve L. Maler" <eve.maler@sun.com>]

Your "concretization" of the consequences of Tim's drawing is very 
helpful!  I hadn't gotten quite that far in my own understanding.

A tiny comment I would make on your writeup is that I believe we are 
only doing BIEs and not CCs, even if they have all their contexts 
"zeroed out", since a syntax binding presumes anchoring to some context. 
  But I may be wrong about this rationale.  (In fact, I've never quite 
understood what it means for an ACC to exist but to have *no context at 
all* -- it doesn't seem possible that something can have a bunch of 
properties as some Platonic ideal, without any context provided by 
knowledge about planned uses of the data.)

	Eve

Grimley Michael J NPRI wrote:
> 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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                     NEW!!! cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com