[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Fallacies of Validation, version #2

• To: "Bullard, Claude L \(Len\)" <len.bullard@i...>
• Subject: RE: Fallacies of Validation, version #2
• From: w3c@d...
• Date: Fri, 27 Aug 2004 14:58:42 -0400
• Cc: "'xml-dev@l...'" <xml-dev@l...>
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE03F9FBE3@h...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE03F9FBE3@h...>
• User-agent: Internet Messaging Program (IMP) 3.2.2 / FreeBSD-4.8

Len,

Amen!

DW

Quoting "Bullard, Claude L (Len)" <len.bullard@i...>:

> 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@d... [mailto:w3c@d...]
> 
> 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@i...>:
> 
> > 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>
> 
> 

• References:
  • RE: Fallacies of Validation, version #2
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: RE: XML Schema views - are they possible?
• Next by Date: Re: XML Schema views - are they possible?
• Previous by thread: RE: Fallacies of Validation, version #2
• Next by thread: RE: Fallacies of Validation, version #2
• Index(es):
  • Date
  • Thread