Last week, a conference Applied XML Developer's Conference, got developers together to talk XML. Experts such as Tim Bray, Sam Ruby, Chris Sells, and Don Box all talked, disagreed, and publicly challenged each other. One core idea was that yes: data does outlast its code.

Summary

One weakness upon which most presenters agree is the ineffectiveness of XML Schema, which Tim Bray, director of Web technologies at Sun Microsystems (and co-inventor of XML), described as "totally beyond its 'sell by' date."

Chris Anderson, an architect on the MS Windows client platform team working on the technologies code-named "Avalon," said developers "hate systems that force XML to be more than data." His answer: XAML (Extensible Application Markup Language), which "provides a format to facilitate between developers and designers … a unified way to build applications to leverage markup."

Sam Ruby, senior technical staff member in the Emerging Technologies group at IBM, spent 45 minutes showing other experts how "the standards don't reflect reality; reality has moved on," particularly in regard to Unicode. Even when default encodings for HTML, XML and Microsoft are different, and XML Namespaces requires that the URI examples be considered distinct, System.Uri.Equals may return "true."

Not every aspect of XML is judged to be a potential disaster—far from it. Two presentations have demonstrated how XML is enabling solutions in the real world: one from the U.S. Department of Defense on using XML for Navy missile systems, and a presentation from Scott Hanselman and Patrick Cauldwell of Corillian about effectively using XML in financial systems.

XML Developers Push for Simplicity

XML is enabling solutions in the real world: one from the U.S. Department of Defense on using XML for Navy missile systems</a>

<nukes>
   <missileSet target="russkies">
       <!-- TODO: don't hardcode this -->
       <launchCode>026537_DUBYA_IQ_0</launchCode>
       <payload>
            <amount>5</amount>
            <multiplier>Megaton</multiplier>
       </payload>
   </missileSet>
   <missileSet target="Them Ayrabs">
      ...
   </missileSet>
</nukes>

LOL. I doubt WS-Security addresses these issues.

Any old lisper hanging out here? Do you feel that XML data could be more easily (and in much more compact fashion) represented by Lisp list. Parsing Lisp list was always the easiest thing to do (just a simple stack machine for syntax). May be more advanced machine for semantics (but semantics is always hard), so maybe a CLOS class templating from schema representation would do.

as an example, the missile system is represented as:
(nukes
 (missileSet
  (target . "russkies")
  ; TODO: don't hardcode this
  (launchCode 026537_DUBYA_IQ_0)
  (payload
   (amount 5)
   (multiplier Megaton)))
 (missileSet
  (target . "Them Ayrabs")
  ...))

One weakness upon which most presenters agree is the ineffectiveness of XML Schema, which Tim Bray, director of Web technologies at Sun Microsystems (and co-inventor of XML), described as "totally beyond its 'sell by' date."

Why are they saying XML Schema is so ineffective? What are the alternatives and what problems do they solve?

Thanks.

One weakness upon which most presenters agree is the ineffectiveness of XML Schema, which Tim Bray, director of Web technologies at Sun Microsystems (and co-inventor of XML), described as "totally beyond its 'sell by' date."

Why are they saying XML Schema is so ineffective? What are the alternatives and what problems do they solve?Thanks.

The issues are manyfold. For example you can't express in XML Schema that an element must either have a particular attribute or a particular child element. You can't express that you don't care about the order of child elements, if the child elements' cardinality is greater than 1. Alternatives would be RELAX-NG or Schematron.

All you have to do is look back (or forward you could argue) to EDI to see where the definencies come into play. Everytime you go to your doctor in the states and an insurance claim is filed, and X12N EDI transaction is sent to the insurance company to pay your claim. These transactions include things like looping records, like "situational elements" where the next element in the transaction has a different meaning based on what the previous element was, variable cardinality, etc.

There are many of these designs in existing business applications that prove highly difficult to model with the existing schema design. If we cannot model designs we have already implemented in so called "legacy" formats, what have we accomplished?

Dave Wolf
Cynergy Systems

I have to say that is a good summary of the limitations I've also come across. Though I've heard excuses from those pro Schema that schema wasn't intended for that purpose. Which in that case, makes me wonder what XMLSchema is good for and why some many companies are pushing it on developers.

One weakness upon which most presenters agree is the ineffectiveness of XML Schema, which Tim Bray, director of Web technologies at Sun Microsystems (and co-inventor of XML), described as "totally beyond its 'sell by' date."

Why are they saying XML Schema is so ineffective? What are the alternatives and what problems do they solve?

http://www.xml.com/pub/a/2003/11/12/schematron.html

http://www.xml.com/pub/a/2004/10/05/tr.html

http://www.schematron.com/

The compact version of Relax-NG is much easier to work with than XMLSchema.

http://www.yaml.org

For the last 4 years, I've been using schema, DTD and XML in one form or another. Most recently, I needed to be able to extend an existing class, which is not defined within schema. JAXB has this capability, which makes it nice if I need extra stuff in my domain objects.

Currently, there is no standard way of declaring a complexType extends or implements a specific type or class. Obviously, schema wasn't designed for the sake of OOP, but I see no harm is making it an option feature.

As far back as 2001, numerous people brought up these issues with the schema group at W3C, but no progress has been made. this is especially true, if one is working in VS.NET. It's common practice for VS.NET developers to generate a schema from the database model. What ends up happening is the generated classes need to implement some kind of listener interface, so their application can perform call-backs.

In the java world, JAXB provides optional features and Castor provides java.beans support. This is one reason I wrote my own Schema compiler for .NET and open sourced it. Having the ability to generate classes implementing/extending an existing class is a necessary part of the projects I've worked on. Of course, if some one only has one database model, it's not a big deal. In case where the schema or database model changes rapidly, I find it much more efficient to provide these extra features for code that can be generated automatically.

I am sick and tired of hearing pros and cons of XML and XSD from industry experts. First it was simple and meant to serialize data, and then they added every dialect possible in this world and now they are saying it is complex. Whose fault is that?

With all the fuss and buzz about XML I found it so ironic that even it is for no use where it meant to be; to export and import data in vendor neutral way form one data source to other. The best you can do is to take the xml file and parse it your self and push it back to the data source. If I would have to do that, why don’t I just use the simple text or data file that is so efficient and easy to parse and manipulate.

I expect tools vendors to use XML, XSD, and SQL Annotations etc and hide the data transformation part and complexity from the end user and automate the whole process. But so far there is not a single tool that can pull this magic (at least I don’t know one) and I don’t know why? May be the experts tell me why:-)

Picking up on a quote from the article where the delegates stated that "data outlasts the code", I think that a better comparison is between data and process. Code models processes after all. Just because the code has changed or been ditched doesn't mean the process has.

Physical data can change as much as code does: it can be stored in different databases, document formats, locations, and its structure also changes over time.

Having said all that, its probably still true that "data outlasts the process". Perhaps thats what they meant?

Someone wrote the following over there

Data: Ever present, ever problematic
data has become the commodity in today's global marketplace. It is not applications, not technology, not even people that drive business -- it is raw data. The tasks of selecting a programming language, picking an application server, and building an application are all byproducts of the need to support data. Thus, those decisions may all later be revisited and changed. (Ever had to migrate from SAP or dBase to Oracle? Ever switched from NetDynamics to Lutris Enhydra?)
However, the fundamental commodity, data, never changes. Platforms change, software changes, but you never hear anyone say, "Well, let's just trash all that old customer data and start fresh."


What do you think about that ?

José.

Reminds me of one of my favorite passages from the paper 'The Trillion-Node Network' by Peter Lucas of Maya Design Group:

In fact, I will argue that, through all the history of electronic information processing, we have succeeded exactly twice at establishing near-universal consensus on elements of information architecture. The first of these was in the 1950s when, after years of experimentation with analog computers and with decimal computers, the bit was once-and-for-all established as the universal first layer of data representation. It took twenty years, until the 1970’s, to reach the second great consensus: the near universal adoption of the 8-bit byte as the second layer of representation. The importance of these two basic standards in supporting interoperability and data liquidity across computing devices cannot be overstated. They form the basis of standard integrated circuits, standard disk drives, communications protocols... they literally pervade all of computing.

Forty years after the bit and twenty years after the byte, what is the likely candidate for the next universally adopted layer? CORBA? The Java virtual machine? I suspect that next step will be more modest....

While folks here argue (constructively, mind you) about J2EE vs .Net, Spring/Hibernate vs Whatever... there are still much more fundamental computing and information issues to be resolved.

I agree that data is a "fundamental commodity."

My business clients are positively hungry for data (past), information (present) and forecasts (future) about every aspect of how their business is running. Data sits at the bottom of this pyramid.

As long as an information system meets a business owner's needs, he or she probably doesn't care how the data is stored or retrieved.

This is not to diminish the importance of information tools and systems. As an information professionals, we must employ systems that meet our needs as well. I just hope that we don't lose sight of the fact that we are, simply, "data servers" to our business clients.

best,
assmund

What a larf, MS's architect said:
"developers hate systems that force XML to be more than data." His answer: XAML (Extensible Application Markup Language), which "provides a format to facilitate between developers and designers … a unified way to build applications to leverage markup."

Translated ... Developers may hate it, but here you go anyway: XML trying to be an application.

I hate to admit it, but I don't hate XUL as much as I should/thought I would. I haven't gotten to deep in it, but you can do some pretty cool stuff, pretty quickly. My understanding of XAML is that it's along the same lines as XUL; we'll see how successful the latest bastardization of XML is in 2005/2006/2007.