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: What Will RepositoryItem Be? (Was: Re: [regrep-cc-review] Kickoff!)


Another issue I'd like us to clarify is what a RepositoryItem for a
CC/BIE would be. Based on our most recent discussions, I think it is
reasonably clear - but I'd like to just make sure we're all on the same

The main question here is: "Is there any reason that we should not allow
for XML representations of Core Components to be stored?"

David mentioned "XML fragments" in (a) below. This means that (for
example) a Core Component named "StreetName" could be stored as a single
element, as shown below (using type "string" for general purposes):

<xsd:element name="StreetName" type="xsd:string"/>

Of course, this would not be well-formed XML. The CCTS spec also
specifically states that Core Components are UML models.

Having said that: 

We know that we need to comply with the CCTS spec by allowing Core
Components to be stored as UML models. This can already be done through
use of an ExtrinsicObject - we would simply have to add an ObjectType or
MimeType that indicates a UML-format Core Component (althought I don't
believe UML has its own mime type). 

Is there any reason that we should not allow for XML representations of
Core Components to be stored? Please note that this would not be the
same as an XML serialization for Core Components - an XML serialization
would "wrap" the StreetName element above with metadata from the CC spec
in XML form. This means we would need two "indicators":

(1) ObjectType = "Core Component"
(2) Object Format = "XML" or "UML" (could use MimeType)

The rest would be up to the submitter to ensure that their
RepositoryItem contained what they intended for it to contain.



David RR Webber - XML ebusiness wrote:
> Joe,
> We're still in agreement on this - its the "how to" that is
> the devil in the details ; -)
> I see two schools emerging -
> a) What Diego has built - which is great for drawing diagrams
>      of maps of things - and consists of XML fragments that
>      chain together like a net map with pointers.  Seems to
>      me this is what the CCTS are hot to have (although the
>      Finnish is tough to read!)
> b) CRI approach - which is a set of semantics about each
>      node in the map in a) above - and aimed at capturing
>       much more details at implementation level - and
>       facilitates the assembly of payloads and their
>       management.
> Thanks, DW.
> =================================================
> Message text written by "Chiusano Joseph"
> >
> I think we're going in circles here between early 2003 and now. Back
> around February, we had a long string of discussions in which all agreed
> that the best approach was an XML serialization (you were one of the
> main proponents of that approach). Have you changed your perspective?
> How are registry users going to assemble schemas from Core Components if
> they are not stored and maintained in XML format?
> <
tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano

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