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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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@CraneSoftwrights.com |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |