RE: [regrep-cc-review] Kickoff!

[Diego Ballvé <diego.ballve@republica.fi>]

> We're still in agreement on this - its the "how to" that is
> the devil in the details ; -)

Agree. And exorcise this devil is what we are trying to do! :)

> 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!)

I have to comment on this:

First, what I've been presenting as "my implementation" is
actually Republica Corp. implementation, backed up by a team
of developers here. I'm just sharing the results.. and I'd
rather call it "Republica's metadata-only apprach" than "what
Diego has built". No offenses though. :)

Second, talking about credits, a lot goes to Farrukh and the
rest of the ebxmlrr team, since we've been building on top
of open-source ebxmlrr, JAXR Provider and RegistryBrowser. A
lot (or MOST) of what you can see in the picture I've submitted
is RIM + RegistryBrowser functionality. We added the content
there. Many thanks to the ebxmlrr team.

Third, I fully agree with you on "Finnish is tough to read",
as do most of non-Finnish speakers around the world. But
again, thanks to Republica's metadata-only apprach combined
with RIM + RegistryBrowser functionality, you can have the
same picture in different languages simply by changing
RegistryBrowser's locale, provided that localized strings
are available. In fact, I have en_US placeholders in our
CC/BIES, but now they simply contain "Name for <finish name>".

<dw>
It also implies that vendors can extend the UI to a registry
so that users can directly query, inspect and create core 
components with the registry - without needing an external
modelling tool - if they so choose.
</dw>

Forth, more than drawing diagrams, you can explore, visualize
existing CC/BIEs, create, edit, remove them from registry. I
mean, you can fully  manage your CC/BIEs. And even if you have
no special interface for that, as you suggested in a previous
mail, just RIM compliance is required to do that.

 
> 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.

CRI approach has its credit and looks great, is probably
easier to read by humans than something like

<ExtrinsicObject
	id="urn:uuid:d7d23f97-f2b3-444c-9d28-ead88997f318"
	objectType="urn:uuid:17aa7899-802f-4d9d-819e-a67d5aa03fab"
	mimeType="application/octet-stream"
	isOpaque="false"
	xmlns="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1">
	<Name>
		<LocalizedString lang="en-US" charset="UTF-8" value="Name for Osoite. "/>
		<LocalizedString lang="fi-FI" charset="UTF-8" value="Osoite. "/>
	</Name>
	<Description>
		<LocalizedString lang="en-US" charset="UTF-8" value=""/>
	</Description>
	<Slot ... />
	<Classification ... />
</ExtrinsicObject>
<Association .../>
<ObjectRef .../>

but I guess we're talking about the same things, just in
different levels of abstraction. As I've mentioned in a
previous 'ps', I also have assembly info, but in a
diferent XML, which I do not store as metadata. Btw, that
might be the way to handle codelists: adding to metadata
just a pointer to another registry document. Just crossed
my mind now..

Anyway, the most important thing is that one level does not
invalidate the other.

Diego