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] Note from the Troll

[ Lists Home | Date Index | Thread Index ]

I like this post. Here are my opinions on your various points 
1.) I've never needed more than Emacs for development or XML editing but I'm interested in hearing what you think should exist in an XML editor that isn't provided in the popular XML editing tools like XML Spy, XMetal, etc. 
2.) No comment. :) 
3.) No robust application should depend on retrieving network resources without a backup plan especially for data as static as a DTD. However I agree with you that problems like this are typically blamed on the technology instead of the implementer or user of the technology. 
4.) The W3C XML Schema recommendation is the result of too many cooks creating a compromise that failed to satisfy most parties. Investigations on my part have led me to believe that most of the percieved complexity of W3C XML Schema is  due to the inaccessibility of the spec which is only a problem because most people end up reading it because there are a lack of online tutorials or guides. Also the recommendation is factored incorrectly. 
The W3C XML Schema recommendation describes four classes of constraints
 i.)  Aset of atomic datatypes 
ii)   A set of mechanisms for specifying the structure of XML (model groups - sequence, choice, all) 
iii.) A set of derivation mechanisms  for simple and complex types(extension, restriction) 
iv.) Co-occurence constraints (key/keyref/unique) 
Each of these should have been its own spec. Then only one spec would have the complexity complained about by most users and it would be (iii) which could be avoided unless absolutely necessary. Even then as long as people kept away from complex type restriction (does 20% of the work but contains 80% of the complexity) they should be in good   shape. 
As for your original point of xs:int and the other types placed there to satisfy the Java and C folks, you can just ignore them in your schemas and only care about xs:integer which has arbitrary precision just like the types in SmallTalk. I've never used 90% of the classes in .NET Framework or Java class yet I've never considered this a problem. People should learn to treat W3C XML Schema in the same way. 
5.) I contest your claim about average developers not being able to deal with the excessive complexity of XML. The complexity of working with XML comes from all the specs built for interacting with XML such as XSLT, W3C XML Schema, SOAP, etc and the average developer isn't using them. The average devloper is sending around custom XML and interacting with it via SAX/DOM/etc. This is a reality that most of us on this list would rather not admit but seems to be the case in my experience talking to and observing developers who aren't specifically working on XML technologies.
I don't have to maintain XSLT files so cannot offer up an informed opinion. However I can point out that the biggest problem with XSLT is that  it is radically different from what most developers are used to which makes understanding it a pain and understanding other developer's XSLT scribblings doubly so. Reading code is hard, rewriting it is easy. This is a general truism of software development regardless of programming language used. 
As for your comments on schemas, data modelling is HARD. Writing schemas for XML is the equivalent of data modelling in the XML space. The average database developer is similarly ignorant when it comes to creating relational schemas and terms like 3NF normalization or referential integrity fly over his head. 
6.) I don't think anyone can argue that relational databases are generally more optimal for storing data than hierarchical ones. As for the rest of your rant, I looked at your link and came to 
"The two tier people caught hold of XML and XSL which appear to address some of HTML's shortcomings. They began to look at web requests as document processing rather than events for a user interface. Except that databases aren't really documents. So to get the database to participate in the XML oriented applications, new mapping models to go from relational databases to XML documents were created. Of course, unlike objects, XML documents are essentially inanimate data lacking behavior. The behavior is supposed to be provided by applying style sheets and transformations to the XML to produce new XML. 

Giant step backwards."

My only question is what exactly the rant has to do with XSLT? Are there databases that convert relational data to XML using XSLT? 
7.) I don't know about other environments but this isn't the case for me as a developer. The primary data sources I am interested in retrieving XML from are objects and relational databases. In the .NET Framework, I have XML serialization for converting arbitrary objects to XML and I can use SQLXML to map my relational data to XML. I believe similar solutions exist in Java and for other relational databases as well but I don't keep track as much as I used to. 

	-----Original Message----- 
	From: tblanchard@mac.com [mailto:tblanchard@mac.com] 
	Sent: Sun 10/27/2002 3:49 AM 
	To: xml-dev@lists.xml.org 
	Subject: [xml-dev] Note from the Troll

	On Sunday, October 27, 2002, at 05:32  AM, Amelia A Lewis wrote:
	> Since I was rude enough
	Quite.  But you weren't alone. The best way to handle a troll is to not
	feed it.
	So I'll just maybe wrap this little fact finding expedition up and lay
	my cards on the table.
	I dislike XML.
	I tried to like it.  I really did.  I read the specs.  I spent time
	trying to develop schemas and DTDs.  I worked on schemes to provide
	additional internationalization information in XML documents (when I
	was chief architect of eTranslate).  I did experiments with XML
	formatted requests over HTTP before XMLRPC or SOAP (which I view as an
	abomination) and I basically invented what Microsoft now calls SOAP
	messages with attachments (using multipart MIME to send additional
	documents) after experiments inlining HTML documents into XML
	Processing Descriptors produced horrendous performance problems with
	excessive escaping and unescaping.  I proposed the MIME thing on Don
	Box's discussion list.  After much derision on the mailing list from
	people just like you, MS published their draft spec for attachments
	about 3 weeks later.  It looked almost exactly like my proposal.
	I also did the Objective C wrapper for expat that a lot of Mac Cocoa
	programmers use.
	Lately, I'm working for a company that is exchanging HR information
	with job boards (like monster and hot jobs) - which has its own working
	groups trying to define HRXML.
	So far, I'm finding:
	1) XML Tools suck - they're little more than syntax coloring editors.
	2) The Hype is at the same level as the hype was for AI and it can't
	possibly live up to it.  It should be written <genuflect>XML</genuflect>
	3) The weight of the processing model is really really heavy.  As an
	example, using URLs to reference DTD's causes all sorts of problems for
	computers when they're off the network.  XML  parsing simply halts. 
	This is especially annoying when running something like BEA WebLogic on
	your machine because you're doing a web app.  BEA stores config info in
	XML which references some DTD at BEA and the server simply won't start
	if that server isn't available.  You can argue this is a misuse of XML
	- I think so - but its one of those things thats going to hurt people's
	impressions of XML.
	4) Schema is really an insane spec.  I mentioned just the data types -
	too many too complicated.  Do we have to specify the number of bytes
	for the ints?  Thats a physical issue and for this Smalltalker it
	doesn't even make sense (Smalltalk handles arbitrary sized numbers).
	5) Like C++, the average developer can't cope with the excessive
	complexity XML introduces relative to its value.  The average
	programmer doesn't really know the difference between nonnegative int
	and positive int.  In fact, the schemas I'm getting from biz partners
	(the couple that want to use XML because everyone is using it - and its
	less than half) are AWFUL.
	XSLT files are maintainable with the same level of ease as densely
	written perl.  Developers asked to modify them routinely rewrite them
	because they can't figure out what the last guy was doing.
	I used to be a C++ guru - zealot in the extreme.  Language lawyer level
	guy.  I worked in it a few years.  I walked away from it one day and
	never looked back because I just got tired of working around its odd
	corner cases.  I then spent some time trying to figure out why the
	people who pushed C++ liked it.  I concluded that they were all very
	smart people.  Too smart.  Because I figured out that they loved
	working in C++ not because it was more productive (its not).  They
	loved it because the thing itself is the damnedest puzzle.  It
	entertained and challenged their intellect to work with it.  I'm
	beginning to suspect the same about XML.
	6) From the stand point of business process and enterprise architecture
	- XML is an evolutionary step backwards.  Hierarchical databases were
	abandoned for relational models long ago and systems made out of lots
	of little scripts gave way to more centralized object model
	architectures because centralization of business logic is more
	manageable.  Model View Controller architectures were created
	explicitly to move the processing knowledge closer to the center.  XML
	"transformations" puts us right back into the same position we were in
	when all the business rules were encoded in the UI and batch scripts. 
	It disperses knowledge without any underlying organizing principle
	other than "a bunch of files".
	I need to write the follow on to this piece but it will focus on point
	6 above plus the assertion that XML fails as both a markup language
	(markup shouldn't require well-formedness) and as a serialization
	format (too hierarchically oriented, verbose, and weirdly structured
	relative to ER models).
	7) While there is lots of heavyweight support for reading XML, there
	isn't any help for writing it from various other data structures.
	So there's my viewpoint.  Take it for what its worth.  Am I trolling? 
	Maybe just a bit - but I'm trying to gain a viewpoint on why people
	think this is moving forward.  I really don't "get it".
	Because it runs against what I've found to be true in my own work. 
	Centralize business logic and ER/OO modeling to model your business
	entities and processes.  This works well when the company has the
	discipline to pick an implementation language and stick with it and
	focuses all developers on this goal.
	But of course, XML philosophy says the opposite.  Where is the business
	rule repository in XML?  Its just carpentry, not architecture.  I'm an
	enterprise architect with many years of telco, cable, and ecommerce
	experience and I see it as harmful to the practice of my craft.
	Have you considered that you're breathing your own exhaust?  You don't
	even agree amongst yourselves on what its good for.  Thats the
	impression you've left me with.  That and some of you have built
	reputations on pushing snake oil for a long time and dare not back down
	Maybe its time for some fresh air.
	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://lists.xml.org/ob/adm.pl>


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

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