[
Lists Home |
Date Index |
Thread Index
]
tblanchard@mac.com wrote:
>...
>
> 1) XML Tools suck - they're little more than syntax coloring editors.
Try XMetaL. It has more than 10 years of evolution behind it. Yes,
that's possible. ;) XML Spy is newer, but also is much more than a
syntax coloring editor. Plus, XML _editors_ are only one kind of tool.
Some research is in order.
> 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>
That isn't a comment on the technology. You could be part of the
solution by taking a realistic view of the strengths and weaknesses of
XML and its appropriate uses.
> 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.
The first sentence makes it sound like there is a problem with XML, but
then you admit it is user error. You could be part of the solution by
documenting this design flaw and encouraging XML users to avoid it.
> ...
> 4) Schema is really an insane spec.
Try RELAX, Schematron or Examplotron. You have options. You could be
part of the solution by helping with the development of these
specifications.
> ...
> 5) Like C++, the average developer can't cope with the excessive
> complexity XML introduces relative to its value.
Tell that to the thousands of hackers slinging around RSS files.
>...
> 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.
When they are used for their appropriate tasks in reasonable ways, XSLT
transforms are substantially easier to maintain than equivalent programs
written in other languages.
>...
> 6) From the stand point of business process and enterprise architecture
> - XML is an evolutionary step backwards.
XML has no stance on business process and enterprise architecture. If
you want to say it is misapplied in those domains then that's fine. But
XML the technology is not the problem.
> .... 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.
You are missing the essential point that XML doesn't cause this problem.
Heterogenity happens. It is what happens when systems are built from the
bottom up, not the top down. Transformations and gateways are the _only
way_ to deal with that heterogenity. The only other option is
standardization from the top-down: an Esperanto edict.
An esperanto edict is of course unworkable, but XML takes us the
reasonable part of the way down the path by saying: "Let's at least use
the same phonemes and alphabet so that we can at least translate between
languages in a reasonable amount of time."
As an analogy, you are blaming the inability of Fracophones and
Anglophones to communicate on the latin alphabet.
>...
> 7) While there is lots of heavyweight support for reading XML, there
> isn't any help for writing it from various other data structures.
Writingis easier than reading (compare the complexity of a code
generator to that of a parser!), so it takes less support.
But for those that want it, there are "data binding" technologies.
> 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".
You could get the information you want without trolling.
>...
> 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.
You've got to be kidding me. You think that GM could have the discipline
to "pick an implementation language and stick with it?" That's a very
frightening prospect: you know already that the language would be Java,
not Smalltalk.
> ...
> 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.
And then there are the thousands of us who chose to use it long before
it was trendy, while Microsoft and IBM were ignoring it and Netscape was
actually fighting it.
Paul Prescod
|
