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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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