How to get content of schema dependencies - XSD's like cm_xml_inst.xsd?

Question

I'm trying to figure out how most easily can get a listing of components which does not validate through with their schemas. This can happen if someone adds a new mandatory field to a schema without doing impact analysis, without considering effect on existing couple hundred or tousand content components.

To solve the issue, I would like to find a way to get a complete listing of these and similar items too, which may fail validating against their schemas.

I'm planning to export/save to local file system all the content components content into XML and also to save all their XSD schemas they use and then validate them.

I noticed in schemas that there are some dependencies, which I can't resolve.

1. cm_xml_inst.xsd - how to get the content of this XSD? Where to access this file to be able to export/save it? This schemaLocation="cm_xml_inst.xsd" for namespace "http://www.tridion.com/ContentManager/5.0/Instance".

2. How to get content of XSD, where schemaLocation="tcm:0-21-1/Categories.xsd"?

I think above XSD's are missing to be able to try to validate the content components to get the listing of failed ones. Also if you know about other solution, let me know!

Thanks in advance! bvl

Update:

Albert's answere: very close to the algorythm I was thinking of.Thinking about programmatic approach and not doing it via UI manually, but the principle you described is very close to what I was thinking of. Would like to check for all components actually (but with an option to restrict it to components using certain schema, like you said), so thinking to programatically read all components and try to save them one by one. Collecting the ones that fail to save into a list. This list will be processed in a second step, going by schema and with the option to apply the same correction to every item using the same schema. This way could automatise and minimize the work I think. Also will probably give this software tool a GUI and to be able to reuse it in future easily.

Dominic's answere: I was trying to accomplish point 2 from Dominic's list, to collect all the schemas used by components and running a validation locally. But seems will choose another approach. Thanks!

Answer 1

To answer your direct questions:

• cm_xml_inst.xsd is in the tridion\bin directory.

• Category schemas are embedded in the publication, and exposed via the CategoriesXsd property of PublicationData by the core service.

As Albert says: the component synchronizer might be useful in solving the problem. There is a command line version available on a branch at the power tools project. It's unsupported, but the full source code is available, and as with most open-source, support can usually be obtained as consultancy.

But the whole point of a component synchronizer is that it's generic and can cope with arbitrary schema changes. For a situation where you know exactly what fix-up you need to apply, you might consider the approach I described here: the poor man's component synchroniser. In most cases, your XSLT would be an identity transform with perhaps a couple of extra templates to take care of your new fields.

Getting back to a direct answer to your question, if all you need to do is find the problem components, then a simple where-used on the schema should be enough. You can then do one of the following:

1. Let Tridion take care of evaluating all the schema includes. Depending on the schema, this might be tricky - with embedded schemas, categories etc., so this may be attractive. In this case, as Albert says, all you need to do is a .Save() on each component. From the API (as distinct from the GUI, which typically won't bother to save if there is no change) saving the unchanged component should be sufficient.
2. Do the schema validation yourself. This would mean calculating all the dependencies and constructing the schema from its constituent parts. (Copy-pasting the included schemas in place of the includes would be an effective brute-force approach).
3. Don't bother trying to distinguish between problem components and the rest, and just run a suitable "component synchronization" against everything.

Answer 2

Obviously you are asking this because someone updated the schema's? (BTW, find that person ;) )

Anyway, you could try the following to find all invalid components:

• Find the schema that was updated (easy: check the last modified date.)
• Do a where-used on the updated schema('s) to get all the components (could take for-ever, consider doing it in chunks (per folder?) (You also might consider creating a virtual folder)
• Open all components, update the title (add ' - checked') and try to save it.

If it fails saving, catch the error and log it somewhere (along with the component-id I guess). If you can save it, undo it because it's valid (or leave it)

Also, did you consider using the Component Synchronizer to fix your issue? (If you are trying to fix the issue. If you are looking for a general solution for this kind of problem, consider using the current Component Synchronizer as your starting point. And of course: give it back to the community :D. Check out this answer for more information about the Component Synchronizer: Alternative to Component Synchronizer)

Hopefully this gives you some pointers on how to get this done. Afaik there is no out-of-the-box solution for this. Correct me if I'm wrong...