CODEWITHSUNDEEP
xmlxsdschema
Alex
Alex

Reputation: 1171

Best practise organizing XML-Schema Files

Say my company has lots of schemas, some for webservices, some for other purposes. There are common type definitions used in many of these schemas via import and also application specific schemas.

Now and then schemas are changed, versioned, and exported.

So far the company uses SVN to store the schema files. They are not structured efficiently, there are redundancies and other problems. There is no clear hirarchy of files and folders.

Question 1: Is it a good practise to use SVN to store and version XSD-Files. What would be an other good approach?

Question 2: How could I efficently structure the files? I would like to organize them in folders correlating the files' namespaces.

Question 3: When exporting, is it more common to give a flattend copy (one folder with all files) or keep the folder hirarchy according to the namespaces?

Upvotes: 3

Views: 1730

Answers (1)

lexicore
lexicore

Reputation: 43671

Here's a piece of advise.

See OGC schema repository for example:

This is one of the largest public schema repositories, widely used in the GIS industry. The schemas are far from perfect, but they've learned a lot of lessons.

To answer your questions:

You should separate the "specification version" of the schema and the "editorial version" or "revision". Once published, you may need to support several versions of one schema in parallel. For instance:

Both widely used in parallel.

So you should factor the "specification version" into the repository folder structure.

"Revisions" should be handled by the version control system. You may (and will) need to do fixes in already released versions.

If your schemas will be public, it might well make sense to put them into a public code repository like GitHub. This would allow your technical users to send you fixes via pull requests. (This is a feature I'd love to have for OGC schemas.) Community input may be very important. XML Schema is not the easiest thing to handle, even experienced devs make errors. The community would help to make things work.

Do use semantic versioning for your schemas. OGC in the current policy uses MAJOR and MINOR in namespace URIs, but not PATCH. So, for the GML 3.2.1 schema the namespace URI is:

The schema URIs do not have to be identical to namespace URIs (compare http://schemas.opengis.net/gml/3.2.1/ with http://www.opengis.net/gml/3.2). If you use MAJOR.MINOR.PATCH in the folder and only MAJOR.MINOR in the namespace - then these URIs technically even can't be identical. But there should be a straightforward transformation. Having an URI like http://www.opengis.net/gml/3.2 I'll know where to look for the schema.

It's good to have one "entry file" per specification, like this one:

Be consistent with structures and naming.

If you have many related schemas in one repository, importing/including one another, better use relative links. This would make easier for other people to download and validate against local copies.

Do not do chameleon schemas. Don't even google it. Every specification should have its own namespace. No chameleon imports.

No, don't do any flattened copies. Why? Just give access to your schema repo plus maybe a ZIP containing all the schemas.

Include a license so that it is clear what the license is.

Check and compile your schemas with several known tools. Xerces, Oxygen, Xmlmind, XML Spy. JAXB/XJC on Java, xsd.exe for C#, PyXB for Python. Make sure it works OOTB.

Provide XML examples for your schemas.

Upvotes: 7

Related Questions