views:

246

answers:

3

Hello everyone!

Talking about schema definitions, what are you used to doing:

  1. put everything inside a unique and big bang XML schema?
  2. use a domain modularization approach, putting all entities that referes to the same context together?
  3. or just use a schema per entity?

I´ve read in a best practice document from a famous/private integration tool, that you should modularize due to performance boost and so on.

What is the best approach?

+1  A: 

One per namespace. Why do you need to break up a schema? I'd also quote the Rules of Optimization Club.

  1. The first rule of Optimization is, you do not talk about Optimization.
  2. The second rule of Optimization is, you DO NOT talk about Optimization.
  3. If your app is running faster than the underlying transport protocol, the optimization is over.
  4. One factor at a time.
  5. No marketroids, no marketroid schedules.
  6. Testing will go on as long as it has to.
  7. If this is your first night at Optimization Club, you have to write a test case.
eed3si9n
One per name space may sound too much abstract. How much modular should be my namespace difinitions?I can have "http://mycompany.com/Customer" (xsd 1), "http://mycompany.com/Customer/Address" (xsd 2). Bu we can have these two difinitions inside the same.
paulosuzart
Okay, rule 7 is funny.
Robert Rossney
A: 

Personally from my experience, I've heard that there isn't too much of a difference either way from a performance standpoint.

In my opinion though, I find a single nested schema to be much easier to understand, follow, and relate to the source document.

Mitchel Sellers
I Will quote the best practice document:"Ensure that the XML document ismodular and small for better performance. It is a good practice to have separate XSDs for eachtype of document."
paulosuzart
One schema per document ys, but I am not sure how much that impacts the performance on the structure of a single document.
Mitchel Sellers
+1  A: 

A schema per entity is spreading things out a bit too much, I think. Typically for a given system, I have a single schema that has all the most common types. That way when I talk about "foo:bar" in one xsd and "foo:bar" in another xsd I know they're equivalent. Then, each context of data go in another schema.

For instance, if we're talking about a finance system, I'd have one xsd with types like order number, invoice number, vendor name, etc... things that all kinds of documents would need. Then there would be one xsd for "invoicing", one for "ordering", one for "accounts", and so on. These schemas may refer to one another as well, and they would each have their own namespace to keep things tidy for any non-common types that happen to have similar names.

Adam Hawkes