Cart
[Home] [By Thread] [By Date] [Recent Entries]
Totally agree, abuse of bureaucracy would be so much easier without those schemas forcing you to be creative. It would be really awesome if in he US I Didn't have to fill in those tax forms precisely and could just supply whatever data in whatever form I wanted, especially if I could skip those pesky constraints about how to calculate how much I owe. I'm converted! Data needs to be free Sent from my iPad (excuse the terseness) David A Lee dlee@c... On Apr 7, 2013, at 6:46 PM, "Simon St.Laurent" <simonstl@s...> wrote: > On 4/7/13 6:00 PM, G. Ken Holman wrote: > > I hope this is considered helpful. > > It is helpful, and it is a case where schemas are clearly not the root of the (dis)order, but it is also wretched in its own way. > > Perhaps the European Union will next attempt to regulate away surprises? > > I'm far from an anarchist, but I'm trying to hold down my dinner as I wonder who thinks this won't lead to strange side flows of information or creative abuse or the many other ills of bureaucracy. > > "The struggle itself through the schemas is enough to fill a man's heart. One must imagine Kafka happy." - Sisyphus Today > > Thanks, > Simon > >> 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. > > > -- > Simon St.Laurent > http://simonstl.com/ > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
