[
Lists Home |
Date Index |
Thread Index
]
Len,
Amen!
DW
Quoting "Bullard, Claude L (Len)" <len.bullard@intergraph.com>:
> 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.
>
> len
>
>
> From: w3c@drrw.info [mailto:w3c@drrw.info]
>
> Len,
>
> GJDXM is a classic train-wreck.
>
> The scary part is people build these schema
> 'dictionaries-of-domain-elements'
> without even determining the use cases. We're back to my - 'oh all we need
> is
> 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
> and
> 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
> to
> get funded for all this - someone must believe they have all the right
> answers.
>
> Oh well.
>
> DW
>
> p.s. fighting complexity is a tough battle everywhere - not just OASIS.
> some
> vendors thrive on complexity - since they figure only their vast team
> resources
> can figure out the implementation details then. Automatic lock-in. Also -
> if
> 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)" <len.bullard@intergraph.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
> > CALS).
> >
> > 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.
> >
> > len
> >
> > -----------------------------------------------------------------
> > 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>
> >
> >
>
>
> -----------------------------------------------------------------
> 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>
>
>
|
