ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ubl-ndrsc] Reusability and Context
- From: Tim McGrath <tmcgrath@portcomm.com.au>
- To: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
- Date: Wed, 16 Oct 2002 16:22:51 +0800
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