Saturday, February 21, 2009
More Thoughts on CMIS
I have learned a lot regarding CMIS from Pie and had some additional thoughts on how this specification can be improved...


| | View blog reactions
- I’m torn here. I believe that CMIS should be 100% supported, but it does not cover everything. There will always be some vendor specific features that will need to be listed.
- As for XACML, it is out and it doesn’t appear to have been close. I’m guessing it has to do with simplicity.
- I feel that taking DFS out of the loop would make for a more efficient implementation.
- This needs to be easy. There are pros and cons to every choice here. Clear documentation is what will help, regardless of the choice. I prefer more self-describing, but I would rather other’s chimed-in on this one.
- How should compression be handled within an ECM SOA? Carefully? This is actually a concern of mine. Simple use-case, a scanned image sits in a repository. It has been decreed that at the stored resolution, it meets the requirements to be a record. Now you compress it for transmission to the consumer application. Is it still an official copy, or just a referential copy for research purposes? I don’t know the answer to that question.
