Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 2013-04-07 15:10 -0400, Simon St.Laurent wrote: >On 4/7/13 12:42 PM, Liam R E Quin wrote: >>If you change "is" to "can be" then I'm OK with the statement, since I >>believe that pretty much any technology or practice can cause problems >>when mis-applied. > >Sorry, Liam. I can't make that change. In fact... > >>I prefer, however, to ask, "under what circumstances are XML Schemas >>beneficial, and when can Schemas (of any kind) sensibly be used as a >>design aid at or near the start of a project? What factors lead to >>success and what factors lead to problems?" > >To repeat and expand: > >... schema-first or schema-centric design, any situation in which >the schema is considered more than a snapshot of current >conversational practice, is actively harmful. Well ... now I think that might be a step too far. >Schemas are in fact, most harmful if used as designed, as foundation >tools for describing vocabularies. They may be less harmful if used >only as documentation, as a snapshot of practice, but even those >snapshots bring the risk of being used in ways that create deep brittleness. Perhaps if you are trying to respond to a flexible environment where data structures are allowed to change to a changing set of criteria or stimuli. But if you have a schema that, say, reflects general accounting principles that are adopted (or mandated; or even legislated), there can be benefit in treating the schema as sacrosanct and going through hoops with your data to match the schema. The benefit is the ability for all to set up processing systems that anticipate everything to be expected without having to accommodate surprises. Companies may be investing a lot of money (building, testing, deploying) to adapt to a mandated schema, but once done they know they don't have to spend more money to react to data not conforming to that mandated schema. The country of Denmark legislated all government procurement invoicing to follow a strict schema. There are even angle brackets in the legislation document itself (they won't do that again because of typos, but that's another story). Now I think 400,000 companies who invoice the government follow a strict schema and the government doesn't need to accommodate surprise changes in the structures that arrive. There is no flexibility in the general accounting principles being followed by the companies ... there is one expression of the information in an invoice that is of interest to the government, and so the government has legislated the structure for that expression. In fact I'm sure auditors would frown upon "imaginative" invoices or invoices that don't follow strict legal requirements. The strict schema accommodates that and is the opposite of "harmful". There is no flexibility required and so benefit is realized by mandating a strict specification. And the entire pan-European government procurement practice is heading towards mimicking what was done in Denmark: total schema-centric adoption of a single structure for each of invoicing, ordering, catalogues and a dozen other document types. So I wouldn't agree with your "schema-centric design ... any situation ... is actively harmful". It would only be so in a situation requiring arbitrary flexibility. I hope this is considered helpful. . . . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training | Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm | Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ | G. Ken Holman mailto:gkholman@C... | Google+ profile: https://plus.google.com/116832879756988317389/about | Legal business disclaimers: http://www.CraneSoftwrights.com/legal |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
