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: Re: [ubl-ndrsc] Reusability and Context


I think both Eve and yourself are correct.  The fact is that we define all CCs as BIEs - otherwise they wouldn't be in our model (as we have a library of BIEs).  That is, we assume a 'context' of NULL and then we build/subtract from that.  There is probably some existential argument against this but in practical terms our approach appears to be fine.

whilst on this thread, to clarify Mike's comment on the slide i showed at the closing plenary.  whilst it is plausible that adding context actually aggregates BIEs (as in his Address - > Party -> Order example), this is only one possible effect.  It is probably more common to see this as Addresss -> PostalAddress - >USPostalAddress or Address ->DeliveryAddress -> FinalDeliveryAddress.  That is context is refined by specifying qualifications.  The fact that a Party may use PostalAddress or an Order may use FinalDeliveryAddress is why Mike's example is correct - but it is describing the effect not the cause.

with this in mind, when we remove context (go right to left on the slide) we can assume that a PostalAddress is more re-usable than a USPostalAddress and an Address is more re-usable than a PostalAddress - because they are more generic components (having less context specific qualifications).

... at least, thats what i wanted to say :-)

CRAWFORD, Mark wrote:
(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,

To use an EDI analogy - think of a segment with all of its associated data elements, codes, etc. Some are mandatory, some are optional, some are extensive and constitute the total requirements of all possible users.  In practical implementation within a particular business context, only those optional elements, codes, etc that apply to the particular business context are employed.  

Mark 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

  

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 



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


Powered by eList eXpress LLC