Hi Joe, Thank you for you attention on this issue, I believe DITA spec allows for external images with scope set to "external" on an image tag. That being said webclient and pub manager both support this functionality in there preview out of the box. I would expect any previews rendering content from a Tridion Doc repo also support the same spec.

Thanks for the suggestion! Tridion Docs has traditionally been the place where customers keep their images, including metadata/workflow and optional rendering of the images. The reason is twofold: the majority of customers want a guarantee that the referenced object will be available at publish time (not possible if managed externally) and in addition the DITA Open Toolkit has tended to assume that image assets are locally available and easy to grab when needed.

We do hear from time to time the desire to more smoothly handle external references, eg to a DAM, in the cases where the customer has a sufficiently mature toolchain to be confident that the assets will always be available in the desired location. There's an argument for saying that that might be more appropriately referenced from an object element instead of image per se. But in any case if this were to be productized then clearly, useful rendering in the authoring tools would be important. (The current rendering you describe in some tools is almost a side effect rather than by design, though I do understand that it has helped a few customers.)

The question then, as always, would be how far to take this. Which image types are rendered. What kind of error if any to show when the target system or object is not available for whatever reason? (Bearing in mind that subject matter experts, the target users of Collective Spaces, should not be expected to understand and resolve such technical errors themselves.) How is this all accommodated nicely and safely in the publishing toolchain (or do we simply trust that customers all have that figured out and don't need additional productized validation?)

It's a good request as I say, so none of the above is to imply that we're unwilling to consider this, just that it needs careful thought and planning, and as with all enhancements, needs balancing against the technical modernization work that will enable such features to be developed more easily in the future.

For now it would be good to hear more use cases around this – I'd welcome input from other users on the value of this and how they might ideally see it working, including the considerations of validation that I mentioned.