[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Kickoff!
Nikola, 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 considered. Cheers, DW. =================================================== Message text written by "Nikola" ><Joe> 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, </Joe> 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 is step [2] in my earlier post, which is IMO job of UBL and/or other similar efforts, not ours. Nikola <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]