Some of this stuff is already in the content repository datamodel, and I think that content-oriented enhancements belong there, not in the underlying object datamodel.
If we stuff too much into objects, then those who keep complaining that objects are too expensive to use in general will have been proven right. And I'd like to avoid that :)
What we are trying to do is to convince people to store content in the content repository rather than roll their own ad hoc solutions. Though I realize people continue to do so, that doesn't mean I want to encourage them. Nor do I want to encourage people to look at acs_objects themselves as being in some sense biased to the building of content types.
And the CR already knows how to expose URLs, how to customize rendering of content types and objects, etc.
Having package_id in cr_items would be very useful. This is the one item on the list that may make sense to include in acs_objects, too. Though finding the package owner via context id - if we follow through and decide that context id does indeed want to be a true parent linke - is fairly simple using the context index map and apm datamodel. The question becomes "how often do you need to do this" ... a time vs. space tradeoff.
Is the PL/SQL call for the name information really that burdensome in practice? Is it certain that this isn't just a result of poor query or page design? Shouldn't we be paginating output rather than listing thousands of objects on a page?
