Shallow-copy schema is compounded from namespace+root + <any> at most nodes + copies of the significant nodes .
I use the Shallow-copy schema for reference to the complicated Schema, when I don’t want the changes in this original schema would influence to the referencing project.
Case 1:
Project A has the complicated schemas. The project B has a reference to these schemas (to the first project).
We expect these schemas could be changed. We won’t change the project B. We expect the changes in the project A do not important for the project B.
Project A has the complicated schemas. The project B has a reference to these schemas (to the first project).
We expect these schemas could be changed. We won’t change the project B. We expect the changes in the project A do not important for the project B.
Case 2:
Outside our domain are the complicated schemas. Our project has to work with these schemas. We don’t care of the most nodes of those schemas. We work only with small bunch of the nodes. Other nodes pass through our application without any changes.
Outside our domain are the complicated schemas. Our project has to work with these schemas. We don’t care of the most nodes of those schemas. We work only with small bunch of the nodes. Other nodes pass through our application without any changes.
Case 3:
Outside our domain are the complicated schemas. Our project has to work with these schemas. We don’t care of the most nodes of those schemas. We work only with small bunch of the nodes. We sure only about the formats of those nodes. Data from other nodes frequently brake up the schema structure.
Outside our domain are the complicated schemas. Our project has to work with these schemas. We don’t care of the most nodes of those schemas. We work only with small bunch of the nodes. We sure only about the formats of those nodes. Data from other nodes frequently brake up the schema structure.
Decision:
We do not reference the schemas from the project A, but create the “Shallow-copy schema”. It copies from the complicated schema of the project A only the namespaces, root node, and nodes significant for the project B.
Other parts of the schema which we don’t care we change to the <any> node/es.
Result:
Only changes in the significant nodes force us to changes in the Shallow-copy schema.
Only changes in the significant nodes force us to changes in the Shallow-copy schema.
Pros:
- Most of the changes in the original schema in project A do not influence to the project B.
- In the project B we really do not reference the “insignificant parts” of the original schema. It’s like a “logical separation” of these projects.
Cons:
- We have to manually create those Shallow-copy schema. [It is one time job.
This job is easy because this Shallow-copy schema is simple.]
- We have to manually change the Shallow-copy schema if changes in the original schema touch the nodes in the Shallow-copy schema.
- The original and Shallow-copy schemas cannot be deployed simultaneously to one BizTalk managing database. This is the most important limit of this
method!
I would realy appreciate your response!!!