RE: [regrep-cc-review] Kickoff!

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

Joe and David,

I'm arriving late to this discussion but I've been trying to follow it.
Still, I'm confused. Do we really need to create a new XML schema for
CCTS? Can't we just map their concepts from UML to RIM's XML?? Won't
we be able to reuse many things from RIM if we choose the 2 approach?
Combining words from both of you, is "our mission" to "create" that
mapping to reuse the available XML?

David, you mentioned performance as an issue against using existing
registry constructs, due to traversing nodes and so on - and I can
tell you that I've experienced this issues in practice - but I believe
you would not be able to put all the information you need into a
single chunk of XML (when working with Core Components), unless the
registry would do some magic and combine all the parts you need into
this document and return it to you. I might be missing something, but
this is how I see it till now.

Moreover, I think that if extra text/binary is to be stored with the
CoreComponent, as repository item, it would probably replicate data
that is already stored as metadata. This would require some
synchronization but might be desirable from user's POV. But its
content can't always be handled by the registry, simply stored.

Now to add something to the list of CCTS lacks, internationalization
is missing in certain places. For instance, although Dictionary Entry
Names can be defined in diferent languages for CC/BIEs, business terms
cannot. Makes it hard to use the synonym feature on searches (although
tech people are most of the times confortable with English, field
specialist may not be or may just want to use localized business terms).
Also, it might be hard to localize restrictions for content components.
Now, I don't think that is the main point of this work, so maybe we
should not spend so much time discussing these issues.

Btw, I haven't introduced myself here but I think I've already made
contact with some of you. I work for Republica Corp., Finland, and
we've used a metadata-only approach for storing CC/BIEs in a ebXML
Registry. I've shared some insights on our implementation of the CCTS
model (not fully compliant but based on the CCTS 1.9 specs).
Unfortunatelly I have no document available to share right now, but
please fell free to ask questions about it.

Regards,
Diego

--------------------------------------------
Diego Ballve
Product Manager
Republica Corp., Products
Survontie 9, 40500 Jyväskylä, Finland
E-mail: diego.ballve@republica.fi
http://www.republica.fi/
http://www.x-fetch.com/


> -----Original Message-----
> From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com]
> Sent: Tuesday, June 03, 2003 11:22 PM
> To: Chiusano Joseph
> Cc: CRAWFORD Mark; regrep-cc-review@lists.oasis-open.org
> Subject: Re: [regrep-cc-review] Kickoff!
> 
> 
> Joe,
> 
> See my inserts below  <dw/>.
> 
> Thanks, DW.
> 
> Message text written by "Chiusano Joseph"
> > 
> and what if there is NO available XML format?!?
> 
> >> There will be - that's what we are creating.
> 
> <dw> ??? Now I'm confused - we're creating XML for UML models? </dw>
> 
> why would we want to store the other binary goup - since we can't do
> anything with that meaningful!!!
> 
> >> An ebXML registry can store this as an Extrinsic object.
> 
> <dw>Exactly what I said - so we do not need XML formats for these</dw>
> 
> If the CCTS folks already think they have that "available XML format",
> 
> >> They don't - that's our job
> 
> <dw>But what are the requirements here? </dw>
> 
> then we need to realize that any non-XML gets either stored 
> as a binary
> - or a pointer to its extrinsic instance.
> 
> >> Yes - how is this different than our current registry architecture?
> 
> <dw>It's not - I was merely stating the obvious</dw>
> 
> And we need an XML serialization system to actually manage the
> semantics.
> 
> >> Yes - and again, that is our mission.
> 
> <dw>And to get the requirements for that serialization</dw>
> 
> But we critically need to understand what those semantics are
> 
> >> Please give concrete examples of what the CCTS does not 
> provide that you
> think it should.
> 
> <dw> There's a long list.  The original CEFACT CRI document we donated
> across - gives 
> extensive details.  CCTS is devoid of rendering or ebusiness logical
> semantics mechanisms.
> They also have no notion of relating sets of vocabularies 
> together - (we
> might just need
> that for a federated registry system) - and being able to 
> cross-walk.  
> There's also little 
> support for what the OASIS CIQ folks are doing with Address, 
> and being able
> to link
> 207 countries postal definitions worldwide together around the single
> semantic core, and
> then have that re-usable as XML that can be assembled as needed.
> 
> And then there is support for automated language usage - 
> particularly in
> rendering.
> 
> And then there is codelists.  Turns out UBL is working on 
> codelists in XML.
>  So is UN/eDocs,
> so is ATG.    Since codelists are a critical core component 
> type - we need
> a clear
> way of not just representing them - but managing them. 
> Including subsetting
> and versioning.
> The CCTS document is quiet on this subject.  The Registry 
> obviously has the
> tools to
> support this - but we are the last people think of - when they go
> engineering.   Since codelists
> are part of CCTS - we come back to my original assertion 
> earlier - that we
> need a
> mechanism that is broadly focused - not just CCTS - since we 
> know in the
> case
> of codelists in particular lots of folks have lots of these.  
>  Also notice
> we have
> performance considerations for codelists.  There are ways we 
> can engineer
> these
> using existing registry constructs - but we may find this 
> would be clumsy
> for extensive
> machine requests - where the overhead of traversing nodes as 
> opposed to be
> able
> to retrieve a single chunk of XML becomes very important.
> 
> OK enough already!
> </dw>
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php