Hi Martijn, On May 19, 2005, at 6:30 PM, Martijn Faassen wrote: [snip] > Is this concept map then an implementation concept map? I am still > at a > loss what the scope of the concept map is in your opinion after > reading > this response. Some of the concepts don't seem to fit on the map > because > you consider them to be UI related, and others don't seem to fit on > the > map because they can somehow be composed out of underlying components > (such as metadata can be built on top of schema). Concerning UI > related > concepts, I do not think any of what I listed is just UI related -- > abstractions on the implementation layer are desirable. > > I have to explain how / why this concept map was written, I think. The concept map was a first draft about what components are needed to build an ECM platform / framework, from the software point of view. So it's more an implementation diagram than a feature map. For example, I don't know how / where to plug in this map "Content Editor". So the map does not contains which features are needed, but which software component we imagine to need to build the platform. It could be changed, and I think your points are important, it's just that the map wasn't written as a feature map. That also why I've said that from my point of view metadata are covered by SchemaEngine (which, for sure, should have the metadata abstraction). Same for document : I think that DocumentEngine + SchemaEngine should manage all document type in the right way. > Concerning concepts which are used to to support other facilities, > I see > on the map that this happens too -- a storage is used to support a > repository for instance, but the repository is still on the map and > not > said to not exist in the 'core framework' as it's all just about > storage > anyway. But I do not see yet how this is different from using a schema > system to build a metadata framework, for instance. > > Maybe because I don't really see what a metadata framework provide ? :-) If you think it's a component, feel free to add it. If you think that store/repository is like schemas/metadata framework, it has to be inside. I think we should also start document on bit part of what is needed, to explain the components / features listed (like what is a component framework, so that we can work a bit on use cases / tech specs. > I am not sure we should be deciding what is in the 'core framework' > or not yet, or perhaps ever (though we should consider "core > distribution"). I am more thinking in terms of building a cloud of > services, so what is core and what isn't should be relatively > fluid. It depends on what people want to work on, after all. > > Of course we can't decide what has to be in the core framework right now. It was only that I wasn't unable to find out that all points were software components and the map was written with this idea in mind (and I repeat it can be changed or we can work on a feature map). > By assuming we're thinking about a cloud of services that may or > may not be built anytime soon, we can avoid discussions about > what's "core" or not, and focus on making some of this stuff > happen. Right now, a big map of what's involved is nice, even if > we're not going to build a large part of it any time soon, as it > helps us think about where we are and where we're going. > > Yes, of course. If you can extend the map, you're welcome, I just didn't see were to put some point because I wasn't able to find how some points can be turned into components (like content editor) from the software point of view. Cheers, EB. -- Éric Barroca, Tel: +33 6 21 74 77 64 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! www.nuxeo.com - www.cps-project.org - www.indesko.com
Hosting: Nuxeo: Zope service provider