[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Re: (CALL FOR COMMENTS) Core Components Specifications
Duanne, The ebXML Registry V2 work removed the contentURI attribute from extrinsic object as it was poorly specified. In V3 there is a work item proposed for URL based access to RegistryObjects and RepositoryItems. So references to contentURI are no longer valid. Duane Nickull wrote: > Dave: > > Thank you for hte further clarification. It will be interesting to see > the plain text format that Rose selects. > > As far as UML not being a syntax - my definition of syntax may vary from > yours slightly. My understanding is that a syntax is a set of "language > rules" or "grammar" for representing something. UML does define the > metamodel however an instance model could be called "syntax bound". > > Regardless, I do think we are conceptually agreeing. > > CALL FOR COMMENTS: > > The ebXML RIM contains an attribute for each Managed Object referenced > by the Registry. It is called "extrinsicURI" which contains a URI > pointing at an electronic file. > > What is the extrinsicURI attribute going to point at when it references > a Core Component? > > I aks this question becuase this needs to be answered BEFORE core > components can be implemented. <QuantumJumpForwardInLogic> Since the > UN/CEFACT approval process calls for two independant implementations, > this question must be answered and in the CC Specification. > </QuantumJumpForwardInLogic>. > > To solve this question, I advocate that we first define all the > requirements for the answer. Here is a starter list compiled from the > comments on this thread so far (from a programmatic AND business level): > > 1. Whatever the Registry references must not be bound to only being > expressed in one single syntax however, it MUST be expressed in at least > ONE syntax that is normalized. Otherwise, implementors will not know how > to parse the Core Component to present representations fo it to other > system actors, whether they be machine or human. > > 2. It should probably contain easily recognizable, traversable links to > the UML model representation of the Core Component AND have expandable > linking abilities to be capable of displaying itself in other formats > (in case something eventually supercedes UML, XML et al as per Lisa S's > comments). I would advocate that the linking mechanism be standardized. > > 3. It should be parsable by applications in a standardized manner. This > is to avoid data serialization errors like misinterpretting a signed > integer as an unsigned interger. > > 4. It should be easy to transform it via an application to other syntax > specific representations of the same object for re-use. > > 5. It should ideally be either human parsable (readable) or it should > be easy to build an application to present a human being a link to a > human understandable representation of the Core Component (ie - text or > UML). > > These represent a good start to the requirements for this yet to be > determined artifact. > > I would like to suggest that we review these and modify/add more > content. > > Duane Nickull > > -- > CTO, XML Global Technologies > **************************** > Transformation - http://www.xmlglobal.com/prod/foundation/ > ebXML Central - http://www.xmlglobal.com/prod/central/ > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC