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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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

Subject: RE: [regrep-cc-review] What Will RepositoryItem Be? (Was: Re: [regrep-cc-review]Kickoff!)


Again this is the crux of the discussion.  

The CRI identified the CC/BIE as the top of the tree,
and under those you link a hierarchy.  That's why I see
the heirarchy approach as the right one.

Take forinstance if the CC is a codelist - there is no way of
managing or implementing that otherwise - right now
all the CC can tell you is 'oh - its a codelist'.   There's 
way more semantics even at that top level that you
could for see capturing in the model about a codelist.

So - while its good to use simple RIM and slots for
the basics - we need to make this more complete
and extensible by having the right design to 
accommodate the realworld uses that end users
need.   Otherwise we have only a theoretical solution,
not a practical solution.

Thanks, DW.
Message text written by Diego Ballvé
>* I mean, when doing business you cannot use a CoreComponent (or
BIE, to be according to specs) but an implementation of it, like
a XML fragment defined by a XML Schema/DTD or an Object (say Java
or C++). I'm not so familiar with EDI but it might follow the same
idea. Again, storing the CC/BIE representation is different than
storing the CC/BIE (idea, concept) and, IMO, should be kept apart.

If they are all to be stored in the registry, they can be stored
as different objects. The different 'implementations' Extrinsic
Objects would be related to to conceptual BIE.

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