Lists Home |
Date Index |
It's called the complexity moat theory of
constraining competition. Serious players
believe in it and it always fails.
GJXDM hasn't been proven on the ground yet.
We use it for exchanges and given some smarts,
it works, but it is deuce difficult to
interpret when getting started. It isn't
exactly a train wreck; more like a jammed
up station. I think it varies in value
depending on where you apply it.
There is user community involvement. The
trouble is likely having a lot of cooks with
limited experience in markup design and also
a need to follow the dictates of the XML Gov
group that made the w3c holy before getting
experience with the technologies. Whatever
the customer wants, the customer gets. No
sales guy causes contention when it gets
to the down select. So money follows fashion.
Also, some of the public safety vendors who
had good running schemas for their systems
hoarded them. Mine was one so I can't be
too critical because the charge can be justly
made that we sat the design phase out with
the motto 'if they design it, we'll code
to it'. Our guys had their heads squarely
in the 80s and missed the web revolution
of community effort and thought leadership.
It was a terrible mistake. We made ourselves
profitable again, but like a swimmer in the
middle of a storm failed to realize that getting
our heads above water for a breath didn't mean
we weren't drowning.
From: email@example.com [mailto:firstname.lastname@example.org]
GJDXM is a classic train-wreck.
The scary part is people build these schema
without even determining the use cases. We're back to my - 'oh all we need
a schema' rant again.
So when the GJDXM people did actually stop to ask user communities what they
wanted - they realized that there was no way that GJDXM can be deciphered
purposed to provide that.
Solution - instead of using CAM - let's invent our own 'CAM'.
Sometimes you just shake your head. But full credit to them for continuing
get funded for all this - someone must believe they have all the right
p.s. fighting complexity is a tough battle everywhere - not just OASIS.
vendors thrive on complexity - since they figure only their vast team
can figure out the implementation details then. Automatic lock-in. Also -
something is inherently simple - why hire legions of consultants? So "the
system" has a vested interested in perpetuating schema - oops - I meant
complexity ; -)
Quoting "Bullard, Claude L (Len)" <email@example.com>:
> Re the dynamics aspect of schema creation:
> While it is fun to discuss AI or other scripting
> programs creating schemas by looking at lots of
> samples, in my experience, this gets done by
> the dudes and dudettes sitting at ends of email
> or telephone pipes exchanging spippets of
> understanding. As Graham notes, most of it
> is hacking examples. I think this is particularly
> true if their is a very large and very abstract
> standard schema with six or seven layers of
> complex declarations in the middle (think
> Justice Global XML or some of the more hideous
> paramerterized DTDs one finds left over from
> I've been watching a new to markup but experienced guy
> trying to negotiate a simple web service interface
> based on GJXDM and I am convinced that before
> it is all done, we'll end up carving that beast
> into something a lot more directly understandable
> and simpler.
> Word to the wise in the Justice Department and
> in the OASIS working groups:
> Simpler is better even if it means more to
> manage, particularly where urgency of
> implementation is high.
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>