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: Re: [regrep-cc-review] Kickoff!


Boy am I glad we're having all this discussion!

Nikola, I believe b) was the decision - and that it is
mis-leading to view this as a "wrapper" approach.   

I agree that is not what we want.  Having an XML serialization
is fundamentally different from a simple wrapper.  It 
implies that the XML hierarchy and content itself enables,
when combined with existing RIM tools, a rich environment
for managing nouns and vocabularies, and enabling the
notion of 'core components' to come to life within the registry.

It also implies that such a environment enables modelling tools
generally to use an active interface to the registry to 
retrieve and store XML content about nouns and so forth
via the normal registry methods.  Documenting this would
be part of the process.

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.

These use cases are vital to understanding the requirements
here - and IMHO shows why this is more than just an exercise
in opening the CCTS spec' up - and using that as the sole
authority to a sound implementation, rather than it being a
useful base set of needs - that then has to be more broadly

Cheers, DW.
Message text written by "Nikola"
I can clarify: We pondered that approach several months ago (updating
RIM to accomodate CCTS requirements), but decided that it was best not
to touch the RIM, but rather to either (a) create a RIM binding, or (b)
express the CCTS metadata in XML format, as a "wrapper" to the XML
representation of the Core Component (i.e. an XML serialization).

We then decided on approach (b) for several reasons,

This is somewhat different then what I'd suggested in my earlier post. And,
I cannot recall that we've decided on (b) -> maybe I missed that decision
somehow. I am strongly opposed to (b) because it is not our job to define
"XML wrapper" for CCTS artifacts. In that way we are doing something that
step [2] in my earlier post, which is IMO job of UBL and/or other similar
efforts, not ours.


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