[
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
Cc:
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".
http://ventedspleen.weblogger.com/discuss/msgReader$21?mode=day
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
now.
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>
|
