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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Fallacies of Validation, version #2

[ Lists Home | Date Index | Thread 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.

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>
> 
> 





 

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

Copyright 2001 XML.org. This site is hosted by OASIS