OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community

Everything everyone else said.

The trick as Steve alludes too is that it is a never-ending job.  Living
languages drift even if only computers speak them.   It is not dissimilar to
schema maintenance for tables with the exception that we don't usually load
table structures with semantics, just relationships.  In XML, that is THE
murky area of practice.

Given my druthers, I'd rather maintain multiple schemas over trying to
convince multiple groups with different semantics in the same community that
they should converge.  The mammal problems are the most expensive.  KISS
really is the best answer as long as you can convince them to do it.

What I see from here is not surprising.  The government throws money at a
problem, the consultants line up, and everyone has a .73 solution for a 1.25
complexity curve so you hammer on the line segment and convince it it is
really an arc-under-stress.  In the name of consensus and ensuring lots of
people got a piece of the tax-burden offset, it all gets hashed into a big
specification family rather than looking at the differences and asking the
question, "Do ya really need this anymore?" and tossing them out.   At the
core of these is the part everyone actually uses 24 x 7.  It is better to
build that and sell lots of copies.  Then at least there is enough
functional software in enough places to make a difference.   Now you have
leverage on the curve to satisfy the cost of pretzel logic.

IOW, unless it is your business to converge schemas, shoot for a core and
sell a product implementing that.  Don't bother trying to convince the
community to sing Kumbayah.  It isn't worth it.  Go straight to their bosses
and show them a product solving a problem they instantly recognize.

Given the steadily rising costs of production with RAD offsetting that just
enough, solid core and obvious ubiquity are the right way to penetrate
markets particularly where there are dinosaurs.  Coming out at night with
furry coats, big eyes, rapid metabolism and a taste for dinosaur eggs is
still the best strategy.   The problem is big lizards aren't agile enough
and the little furries have to multiply fast or be lizard food.

No free lunch.  A day in which no code was written was wasted.


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS