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] constructive (was RE: [xml-dev] Markup perspective not co

[ Lists Home | Date Index | Thread Index ]
  • To: "Didier PH Martin" <martind@netfolder.com>,"Simon St.Laurent" <simonstl@simonstl.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] constructive (was RE: [xml-dev] Markup perspective not code)
  • From: "Dare Obasanjo" <dareo@microsoft.com>
  • Date: Sun, 4 Aug 2002 13:14:29 -0700
  • Thread-index: AcI78cr+BtkaLJIWS3+SbC1qWkBsDQAALxvE
  • Thread-topic: [xml-dev] constructive (was RE: [xml-dev] Markup perspective not code)

Isn't suggesting that only the W3C be allowed to specify APIs or programming language specific technologies for dealing with APIs the very definition of creating a monopoly? 
 
I like the fact that I can use XPP, JDOM and Castor in Java or their equivalents in the .NET framework without having to deal with APIs that are inconsistent with the rest of the class libraries, fail to utilize the programming language idioms and ignore general language specific design patterns. 
 
Choice is the very antithesis of monopolies. 

	-----Original Message----- 
	From: Didier PH Martin [mailto:martind@netfolder.com] 
	Sent: Sun 8/4/2002 1:01 PM 
	To: Dare Obasanjo; 'Simon St.Laurent'; xml-dev@lists.xml.org 
	Cc: 
	Subject: RE: [xml-dev] constructive (was RE: [xml-dev] Markup perspective not code)
	
	

	Hi Dare,
	
	Dare said:
	I disagree with you and completely agree with Simon on this regard.
	
	Platform and implementation specific technology like how to map XML to
	programming language objects is the last thing that needs to go through
	the design-by-commitee/lowest-common denominator process that has
	characterized the W3C's efforts in coming up with programming language
	related standards.
	
	This is exactly the problem with the DOM which you rail against. One
	standard API for all languages regardless of whether staticlly or
	dynamically typed, weakly or strongly typed, garbage collected or not is
	bound to be insufficient many cases. Add the fact that this API will
	have to ignore programming idioms, design patterns and naming
	conventions in most of its target languages since it will just pick one
	means that using it will be counter-intuitive from using other APIs in
	these target languages.
	
	Didier replies:
	I agree that some languages cannot support any dynamic creation of
	objects. This is probably why we ended up with the DOM and static
	objects like elements and attributes. However some other languages like
	ECMAScript allows that. By trying to isolate the processing from the XML
	syntax and not picking at least a prototype language we end up with a
	situation where we sit between two chairs. And even strongly typed
	languages could be adapted to XML element trees. It seems that we are
	trapped in a single paradigm and that paradigm is not what the core
	mainstream developers need. This is why we end up with other solutions.
	This has nothing to do with all the syntaxic complexity we face today.
	It has to do with insufficient tools or tools more archaic that we used
	to have. Without any standardization organism, we let monopolies to set
	one. Are monopolies working for the users? In part yes but they mostly
	work for their stockholders.
	
	Cheers
	Didier PH Martin
	
	
	





 

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

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