Clever Geek Handbook

How modular should an XML schema be?

Speaking of schema definitions , what did you do:

  • puts everything in a unique and large XML hacking schema?
  • use a domain modulation technique by putting all entities referencing the same context together?
  • or just use a schema for each object?

I read in a best practice document from a well-known / private integration tool that you should modulate due to performance gains etc.

What's the best approach?

+1


source to share


3 answers


I think the schema on the entity extends things too much. Usually, for a given system, I have one schema that has all the most common types. Thus, when I talk about "foo: bar" in one xsd and "foo: bar" in another xsd, I know they are equivalent. Then each data context goes to a different schema.



For example, if we are talking about the financial system, I will have one xsd with types like order number, invoice number, vendor name, etc ... things that all types of documents will need. Then there will be one xsd for "billing", one for "order", one for "accounts" and so on. These schemas can also refer to each other, and each has its own namespace to preserve the order of things for any non-generic types that have similar names.

+1


source


One per namespace. Why do you need to split the circuit? I'll also quote the Optimization Club Rules .



Edit: If you have a lot of objects that don't overlap with each other (plugins for example), it might make sense to start applying DRY / modularization and break down the common parts.

+2


source


From my personal experience, I've heard that from a performance standpoint, there isn't too much difference.

In my opinion, however, I find that one nested schema is much easier to understand, follow, and relate to the original document.

0


source






More articles:


All Articles