Re: [xml-dev] Not using mixed content? Then don't use XML

[David Lee <dlee@calldei.com>]

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@calldei.com


On Apr 7, 2013, at 6:46 PM, "Simon St.Laurent" <simonstl@simonstl.com> 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>