> This doesn't have any document specific BIEs and I can
> appreciate your point made earlier that there may be a
> requirement to have such.
>
> Having any document specific BIEs causes problems similar to
> those which required all Codes and Identifiers to be global -
> if the BIEs have the same namespace as the document - or so
> it seems from the work I've been doing with prototyping
> designs and checking their implications.
Could you please identify the problems
> So if we do need (I admit I can't see why very clearly) any
> document-specific BIEs then I think we'd possibly need an
> external schema module for them.
I guess I need to see the problems first before I could agree with this
assumption
>
> 2. I'd think an idea worth considering would be to have a
> document-specific module but with another namespace.
That is the part I don't yet understand - why a different namespace
>I'm thinking that in future it might be a suitable place to
> derive more suitable document specific types from common or
> core types so that, for example, an OrderLine in an Order
> doesn't have to include all the ASBIEs which are really there
> just for use in the OrderResponse
You just hit the nail on the head as to why we need Core Components.
With a core component of Line and BIEs of Order_Line and
OrderResponse_Line, you can segment the ASBIEs.
> This would cut down a lot on the overbloating of documents
> (one of the problems the SBS incidentally helps to solve).
The bloating and conflicts of the library are caused because we have
tried to use BIEs in a way that was never intended - as the CC and BIE
together. As a result, the BIE is both a conceptual data model and a
physical data model. CCs are intended to be the kitchen sink that never
ever get used for any purpose other than as a harmonization tool. BIEs
are supposed to be specific assemblies for specific contexts in specific
exchanges - qualified and customized through restriction from the
conceptual CC.
Mark
