Remember when XML first came about? It seemed so simple. You even *could* kinda read the documents and understand (guess) what the different areas were meant to be. Things have definitely moved on though haven't they. Now we have a myriad of technologies to try to understand, and many choices.

View the simple picture of where we are today:

The XML Family of Specifications

Also, James Clark (mr. xml... or one of them) has released his latest XML invention, the Namespace Routing Language (NRL). According to Clark, "The XML Namespaces Recommendation allows an XML document to be composed of elements and attributes from multiple independent namespaces. Each of these namespaces may have its own schema; the schemas for different namespaces may be in different schema languages. The problem then arises of how the schemas can be composed in order to allow validation of the complete document. NRL attempts to solve this problem." NRL can combine schema in arbitrary schema languages.

Don Box (a.k.a. spoutlet.microsoft.com) had some clarifying comments.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Pretty amazing to see what has become of XML, knowing from years of experience that the majority of the benefit of XML can be had with simple tags, attributes and
URL encode/decode instead of CDATA -- nothing else, no DTDs or any of the etceteras! Inhouse, anyway; if you go outside, add mutual agreement to that list.

After all, all you really only need a few simple cutting instruments.

Anyone that can look at that XML diagram and be 'proud' of how far we have come I assume would also look at a large stack of bureaucratic rules out of some dystopian nightmare (ala 'Brazil' - the movie) and be proud of the government that produced it ;-)

Elegance and simplicity should count for something too and is something that XML did strive for in the beginning, (otherwise why would bother to even consider such an inefficient representation), but which now seems a distant memory.

Some folks are even using XML notation for programming languages. This is really going too far, unless of course they mean for it to be LISP-like. But they don't.

Anyway, what we really need to work on is ways to make the use of XML, where appropriate, transparent. It is a data-representation scheme, after all, and software should simply map to and from it without the user knowing about it at all.

Users need greatly simplified interfaces. For example, I wrote an "accessor" class that takes a textual XML expression, parses it transparently, and lets the user access any datum using a path notation. The user needs to know that his data is hierarchical, but does not need to know XML. Then I wrote a "builder" object that takes a path and a value, and plugs the value into that location (creating the location if necessary), and at any time can spit out the textual XML expression, for example to a file. So the user can access and/or create XML with no knowledge of XML, just a knowledge that the data is hierarchical. It's a 12K parser and XML object, and 20K for the accessor and builder. This has satisfied most of my XML requirements.

It looks like most XML-centered activity prides itself on making XML more complex by stretching its uses beyond appropriate data representation.

Anyway, what we really need to work on is ways to make the use of XML, where appropriate, transparent. It is a data-representation scheme, after all, and software should simply map to and from it without the user knowing about it at all.

Ie, JAXB.

Hi,

has anyone married jaxb with (j)xpath in a project? These are the technologies (and Eclipse XSD Infoset Model - I forgot to mention) we're using in our current project.
The constraint we are having: the application receives a xml schema only at runtime, not sooner.
Oh well, at least we're having fun.

Stefan Chis

You should try XMLBeans.

XMLBeans combines the simplicity of Java-XML binding with the power of an xml cursor for DOM like access to the XML. In addition, XMLBeans can be used to query the xml through xpath or xquery.

An online version and more information is available at http://dev2dev.bea.com/technologies/xmlbeans/index.jsp

I am not smart enough to learn all of this.

I have been using JDom for my XML and .... it does what I need it to do.

.V

I've been in the software industry for a very long time. It makes me really proud to look at the big roadmap picture (http://kensall.com/big-picture/bigpix22.html) and to realize how far we have come.

I'm looking forward to the next step in XML: Security. It seems to me that digital certificates and SSL are well established on the server side, but that they never really took off on the client side. So I can't really depend on certificates to encrypt fine grained data from a client to a server in a universal way - sure I can learn all the APIs to encrypt an element in an XML document, but I want some universal way to do so that doesn't require me to step outside the language I write in to enable the security mechanism.

-Frank Cohen
http://www.PushToTest.com
TestMaker 4.0 now features live charts and meters

P.S. I wish the big roadmap wasn't color coded - for us color blind folks. :-o

are you trying to be funny?

I bit, and went to www.pushtotest.com.

What's up with that? What is Push To Test.com?

I guess it comes as no surprise when I say that the big XML picture is out of date and it's better to wait for the next edition. To prove my point, where is XUL?

To find out more about XUL (XML UI Language), check out the XUL Alliance site @ http://xul.sourceforge.net

- Gerald

A family of specifications? All based on the same foundation called XML?

Excellent. Allows me to do security (XML Security), send trading docs (ebXML), write deployment descriptors for J2ee and web.xml for web servers. A great java build tool called 'Ant'. All courtesy of xml.

Too many disparate legacy technologies?? Two different worlds (open source & Proprietary) and one glue( XML :- SOAP)

XML invention is as big as the founding of the internet. It will go a long way in helping build software systems.

But we have so many specs under the umbrella that it is difficult to have knowledge on most of them. Also, most of these specs mate day in and day out, (mutate day in / out) and beget more specs.

Do you think we need a spec for each thing?? Can't we have a framework spec that reduces a number of individual specs.

We are constantly finding places to use XML, only to replace it with more traditional solutions when performance becomes critical.

XML could focus on client-side data storage to simplify fat-clients. This could be place where XML has an advantage.

Despite all the hoopla, when the dust settled we've discovered that using a framework, such as Castor, to deal with XML behind the scenes (or, under the hood if you will), seems to be the best way to go. That way, we don't ever have to think about XML (not even being aware that there is such a thing as XML), save for the XML Schema. Simplify, simplify, simplify!

But then, we found that XML Schema is the ideal business documenting tool. We now lean towards replacing any tedious behavior, that may stem from the various XML-related technological specification, with the behavior of our custom business objects. The object know how to persist/exchange their states by leaning on the underlying framework (usually by sending the marshal/unmarshal messages; simple as that).

Are we missing something here?

Alex

I think it's a little misleading to title this graph "The XML Family of Specifications". That would imply, to me, that all of these specifications either define XML or define some specification for transforming, verifying, disambiguating, manipulating, searching, whatever-ating XML.

However, a whole lot of the boxes on the right half of the map are simply formats that use XML (ebXML, LegalXML, MathML, WDDX, SOAP and its brood, XML-RPC, SVG, VoiceXML, etc.). That's like pointing to a huge list of Java programs and saying "look how complicated Java has become".

That said, XML itself *has* become extremely complicated and does cover an ever-growing number of specifications. Just not as much as this picture would have you believe.