The annual winter XML conference hosted by IDEAlliance took place
last week in Philadelphia. I had skipped last year's conference in
order to spend a December without travel, and had found I enjoyed that
idea very much, so I was a bit skeptical about going this year. But
in the end I offered two talks about XML Schema 1.0, and I'm glad I
went. Perhaps absence makes the heart grow fonder, or perhaps it's
just that Philadelphia is a more attractive venue than Disneyworld
(where the 2001 conference was held). Reading Terminal Market by
itself is a great asset to any convention: you can mingle with real
The talks were, as always, a bit of a mixed bag. There were some
wonderful talks from which I learned a lot; there were some plenary
talks which were so awful they successfully drove attendees out of the
room; there were many in the middle. In addition to the official
program, I had good conversations with Henry Thompson (mostly XML
Schema Working Group business), Janet Daly, Jonathan Robie (Jon Udell
is urging him to start a blog, and he turned around and urged me to do
so, too), Peter Fankhauser (whose work on using XSLT to make highly
interactive interfaces to XML data looks really cool, and
who reports some interesting events in Darmstadt), Tommie Usdin,
Debbie Lapeyre, and Jim Mason (planning for Extreme Markup Languages
in Montréal this August), and others.
For whatever reason, I thought it was a great conference.
Herewith a highly selective and subjective summary of my week.
1. Jon Udell, The social life of XML
The opening plenary session featured a keynote by Jon Udell of
InfoWorld. I enjoy his columns (and have enjoyed his weblog when from
time to time I remember to take a while to read weblogs), so it was no
great surprise that I enjoyed his talk.
XML, he started out by saying, is changing the way organizations do
business. But is it changing the way that people in
those organizations do their work? Can we separate those two
questions so easily?
The key idea of XML, he continued, is that database data and
documents are made of the same underlying ‘XML
stuff’. Because that is so, it seems likely to become
feasible to allow users to navigate, without visible application
seams, through all of the data they have an interest in. Because XML
makes it easier to retain information about the (original) context of
the information, the information experience can be richer. He quoted
Brown and Duguid, The Social Life of
(which looks to be worth reading), and
recalled to our mind a couple of old marketing efforts about seamless
information spaces, both the old Microsoft slogan about the
‘universal canvas’ and the old Apple Knowledge
Navigatore video. (He also quoted Tim Bray and Jean Paoli and
Jon Bosak and others, perhaps as a way to establish that he does
have his ear to the ground and listens to the right people.)
As examples of how XML and standards and off the shelf components
can help bring these old slogans to life, he showed a simple tool he
built for searching arbitrary XML, demonstrating its use to search the
document containing his slides (“Is the talk too quote-y? How many
slides actually contain quotes, and from whom?”).
As one might expect, he was mostly positive about the integration
of XML into Office 2003, but he thought Microsoft had seriously dropped
the ball on one thing: email, he said, remains the primary lubricant
of our business processes, but Outlook is the one
Office application where users can't create or use XML data.
He suggested that the Draconian error handling of XML 1.0
(ill-formed data must not be let past) might be setting too high
a standard; it's amazing to watch highly paid professionals spending what would
otherwise be billable time trying to make their data well-formed.
The XML parser is there to prevent incursions by the barbarians,
he said. But what we really need are not
ways to keep the barbarians out but ways to allow them to become
useful, productive citizens.
As an example, he talked about hearing someone (Ray Ozzie) complaining
about the difficulty of exchanging calendar information, and about giving
an example to show how it could be done. His data was, accidentally, ill
formed. But the browser was able to make some sense of it, which Udell
counted a bit of a victory. If we can squint and make it well formed,
then we can make it more useful.
He didn't persuade me that Draconian error handling is a bad idea:
its purpose is not in fact to keep barbarians out but to prevent
the spread of tag salad, which has historically been the gray goo
of the non-XML Web. And so far, I am inclined to think it a success.
He did persuade me that tools like Tidy, which
can do the squinting for us and help civilize the barbarians,
are a good idea; he just didn't persuade me that they should be
built into the XML infrastructure.
In a way I didn't quite understand, he suggested that XML's strictness
may be responsible for the shortcomings of our editing technology.
A long time ago, off the shelf HTML composers were at 80% of
the required functionality (as Jon Udell sees it). They still are.
They haven't moved forward.
Meanwhile, we have lots of things for XML authoring. But they are
all focused on structured, well designed stuff. (In retrospect, I
think he means they are all focused on XML that doesn't have mixed
content or support natural document structures — true for many,
but I think “all” is stretching it a bit.) They don't appeal
much to people, because as Jean Paoli has said (and in my opinion
this quotation was worth going to the conference for), “someone
who puts in a penny of effort on structure or
data cleanup expects a penny of result in return.”
In conclusion, he suggested, we don't need to wait for Microsoft to
deliver Cairo. We have the raw ingredients now and we can move
forward in a more inclusive way, by using the combination of XHTML,
CSS, and XPath. CSS in particular is a great opportunity for
smuggling metadata into documents: Let's build packages of style tags
that make things look good. And then build tools that do useful things
with them. And then people will put metadata into their documents
just so they can use our stylesheets.
With these tools, we can get serious about using XML to capture
real-world context. In this endeavor, XML's publishing DNA (he means
mixed content again) is a great asset. Let's not just bring XML Web
Services to the desktop, let's put them on
it. Because the pipelines are XML, we can inject intermediaries who
observe and who capture a lot of context from what they observe. (At
this point, to my surprise, he did not quote Yogi Berra's
dictum “You can observe a lot just by watching”. But it was
a good peroration anyway.)
2. Other talks
After the opening plenary, I was somewhat less studious in taking
notes of talks, so I can't summarize the other talks I heard in
anything like the same level of detail.[1
] There were also many, many talks I wanted to attend
that I didn't make it to owing to scheduling conflicts. (I felt like
asking my own audiences what they were doing in this room, instead of
listening to the great talks going on next door and down the
2.1. Garvey and French, Generating user interfaces from composite schemas
This talk described a tool which takes XSD schema documents as
input and produces an XForms-based user interface as an output. It
differs from some earlier efforts in this direction by making fewer
limiting assumptions about the schema and being able to accommodate a
larger range of schema coding styles.
I remember some members of the XML Schema WG suggesting that
schemas could be used to generate user interfaces, and others arguing
vociferously that we must not mention it as a possibility since real
user interfaces would require additional information. It seems that
both groups may have been right: it is possible to
generate a user interface straight from the schema, and it
is often desirable to modify it or tweak it manually (in
this case by adjusting the stylesheet which controls the XForms
2.2. Megginson, Strange creations
This talk was hard to follow, as long as I kept looking for a
thesis, theme, or argument — that is, as long as I kept
expecting it to turn into a normal conference presentation. Once I
got past that expectation and regarded it as just an opportunity to
shoot the breeze with David Megginson (in a rather one-sided
conversation, to be sure), I was able to enjoy it: David is very
clever and fun to talk to, and here as always he had useful and
interesting things to say, which more or less absolutely defy
The overall thread of the talk was a presentation of various
prototypes for delivering XML data to desktops. Alas, although I
assumed the talk's title was an allusion to Strange
fruit, there were no Billie Holiday references.
2.3. Dubinko, XForms: Bringing the power of XML to everyone
I think XForms are going to be an extremely useful tool, because
they will make it feasible to produce large numbers of specialized
editors for specialized XML data manipulation / cleaning tasks, which
are easier to use than full-bore XML editors (because they will have
much simpler user interfaces) and also much safer (because there is
less damage you can do to the underlying XML if you do something
wrong in the editor); for the latter reason, I call them ‘padded
cell’ editors, although from people's reaction to that term
I think perhaps another name would be in order. “Safety-razor”
editors doesn't seem to be quite right, either.
So I was happy to see Micah Dubinko giving a good introduction to
XForms. He's kind of a quiet, subdued speaker, and I occasionally wished
for circus parades and calliopes to attract more interest, but he got
the job done.
2.4. Joshua Fox, Knowing what your schemas mean: semantic information management for XML assets
Joshua Fox of Unicorn Solutions gave an interesting view of what
semantic information management might mean.
He began by asking: if I'm in a typical organization, with tens or scores
or hundreds of ad hoc schemas written for various overlapping tasks, then
how do I find an appropriate schema for a given purpose?
It's not easy: simple text search doesn't necessarily work the way
you might wish. If I find a salary element, is that
the monthly or the annual salary? If I find a complex type named
Q282X2 (created by an automatic schema generator), how
on earth do I know what it means? Does the complex type
Employee include the relevant salary information
(perhaps nested very deep below the surface)? We want to minimize the
round trips asking the business analyst to tell us what on earth
Today, business and technical analysts work together and create new schemas;
when a new one is needed, it's too much trouble to reread any of the documentation,
so the point of least resistance is to create yet another schema. That's how you
get to 60,000.
That's the problem.
What's the answer?
Semantic information management is the answer. This goes a bit
beyond what most of us mean by information
management. We are going to go beyond information
managment by using formal semantics.
Centered on a semantic hub with a central information model;
everything around it is XML schemas.
The central information model represents the real-world entities of
the business; it models the real world. It looks a lot like an XML
Schema document, but it's modeling the world, not XML documents.
The ontologies we are talking about resemble OODesign, ER modeling,
or UML. But they are focused on real-world entities, not software or
What's in the ontology? Classes (e.g. the set of all power plants;
energy, identified as the concept of energy as defined in physics).
Inheritance (e.g. in the U.S., State inherits from Region). Properties
(power plants have outputs, names, ...).
Business rules constrain properties and link them together.
Uniqueness (no two people share SSN), enumeration (power plants have
type = hydro, nuclear, coal, or wind); mathematical or other logical
relationships: kilowatts = watts / 1000.
Mapping associates schema types and elements with concepts in the
semantic model. Complex and simple types map to classes; elements and
attribute map to properties.
“The standard for schemas is, of course, XSD.” For
ontologies, OWL and RDF.
Example: consider this schema. Now imagine it's lost, and you want
to reuse it. How do you find it? Finding all the power plant schemas,
and none of the botanical ones.
Other applications of semantic information management.
Generating schemas: the business needs, as represented in the
Semantic Model, can drive the automated construction of a schema.
Transformation: given source and target schemas, the semantic
architecture ‘understands’ them and so can generate
XSLT to transform from one to the other.
Working with non-XSD schemas. All of these ideas can be applied to
other kinds of schema languages: cobol, xml, ERwin schema,
Rosetta-Net, Custom XML Schema, ...
Web services: web services are described by WSDL. The input and
output messages of each operations are described by XSDs.
The biggest problem I saw in Joshua Fox's account is one that often
comes up in grand semantic plans. If (as explained at some length in
the setup) part of the problem we are trying to solve is that the
human or machine creator of the schema could not be bothered to write
down a sentence or two saying what the salary element
or the Q282X2 type mean, what are the chances, in
practice, that they can be persuaded to write up a formal semantic
account of the elements and types in their schema?
I also missed any sign that the system involved deals adequately
with the fact that much of the semantic information that needs to be
captured will come in the form of relations, not atoms.
(Specifically: it's not enough to say that the contents of a
salary element are an integer, written as a decimal
number, representing the annual (or bi-weekly) salary. That's
important, but if you don't record the fact that that salary is
associated with a particular employee, you haven't captured the
meaning of the markup. That relation is far too important to remain
implicit in something aiming at a formal account of semantics.
2.5. Gutentag and Gregory, UBL and object-oriented XML: making type-aware systems work
Eduardo Gutentag and Arofan Gregory gave a wonderful talk about
their work using XML Schema types to support versioning.
XSD, they noted, contains OO features inherited from SOX; the
intent was to enable a specific kind of OO design, with UBL leverages.
In this talk, they summarized points raised in detail in a series of
four preceding talks (Extreme 2001, XML 2002, XML Europe 2003, and one
other which I clearly haven't found yet).
The Universal Business Language has just been released as an Oasis
draft; it's both a library of types and a set of schemas which are
generic in scope (cross-domain within e-business)
designed for customization (‘contextualization’)
and based on the ebXML Core Components modelling methodology.
They outlined their basic use case for schema versioning. Imagine
that you are a processor with hard-coded semantics for version 1.0 and
1.1 (say) of a core vocabulary. Life goes on, and in due course
versions 1.2 and 1.3 of the spec and schema are released, but for
whatever reason you are not updated. Now you receive a message
encoded using the 1.3 schema. Can we design things so that you can do
the right thing even though your hard-coded semantics are only for
version 1.0 and 1.1?
The approach taken in UBL follows these rules:
All modifications made to schemas to reflect customizations or
minor versioning changes must be expressed using XSL additive
extension and/or subtractive refinement. (I.e. the 1.1 version of a
type must be derived from the 1.0 version of that type.)
All minor versions exist in their own namespaces, and import the
namespaces of the preceding minor version.
All customizations exist within their own namespace, which
imports the UBL namespace containing the types to be
To restate the versioning use case in UBL terms: trading partner A
transmits a version 1.3 document to partner B, which processes the
document as if it were a version 1.1 document. Since type derivation
guarantees that the 1.3 instance contains what is
necessary to make a valid 1.1 document, it's OK.
If the later-version or customized schema type was derived by
extension, rather than restriction, there is some danger that a data
deserializer hard-coded for an earlier base version may lose some
information. (N.B. the schema validator doesn't lose the information,
but if your processor deserializes the XML into objects and then works
exclusively with the objects, then you may lose information if your
deserializer drops the extra elements at the end.) This has
consequences for writing (serializers and) deserializers: if they get
extra stuff they don't understand at the end, they should provide a
place to put it so it can be carried around.
They identified four styles of schema writing (these terms are
now more or less current in the community):
- the russian doll (one top-level item, everything else local)
- the salami slice (types global, elements local)
- the Venetian blind (elements global, types local)
- the Garden of Eden (both types and elements are global)
Application design implications:
danger of data loss (but there are solutions: don't
drop the data on the floor just because you didn't expect it)
greater interoperability (across customizations and minor
requirement for namespace/type hierarchy management
For non-type-aware applications, they said, there is no cost,
Negatives: run-time schema processing is required. You have
to have access to the schema at run-time. Some people don't do this, for
performance reasons; here, though, it's a requirement. You have to manage the
type hierarchy and namespaces to enforce business requirements; you have
to prevent data loss and meet legal requirements.
Positives: much better interoperability across minor versions,
customizations, and so on. You are likely to have no control
over version support in applications, and no control of versions used by
new trading partners or customizers.
2.6. James Clark, Namespace routing language
James presented work he has been doing on validation using
not only different schemas for different namespaces, but different
schema languages for different namespaces.
He began by saying that namespaces have significant cost; their
benefit is to avoid ambiguity when
there are multiple vocabularies
vocabularies are combined in a single document
vocabularies are developed independently
vocabulary boundaries are unpredictable
They have implications for validation: we want to take advantage of
namespaces without losing the benefits of validation. But
independently developed vocabularies will have independently developed
schemas. We need to be able to validate a document using multiple
namespaces, where each namespace has its own independently developed
One approach to this: you settle on a single schema language, and
use it to define each namespace. This requires, of course, a language
with facilities for combining schemas for different namespaces.
An alternative: multiple schema languages. Why use multiple schema
languages? There are multiple useful paradigms: grammars, queries,
keys, OO, etc. Multiple small complementary single-paradigm languages
are, James believes, preferable to a single large multi-paradigm
] Also, application- or domain-specific schema
languages are useful (e.g. RDF).
Each paradigm (argued James) has its place. There is a huge
spectrum of use in XML, and a huge spectrum of constraints people want
to impose. You can of course just write code to to validate your
application — but if you validate using executable code, you can
only use it for limited purposes. If you write a grammar (or more
generally, if you express your constraints declaratively), you can use
it for other things: editing, data binding, etc.
James prefers small, single-paradigm languages. Using them, he
said, makes the evolution of schema languages more straightforward.
Rather than being afraid of multiple schema languages, one should
“I guess the dominant schema language today is probably W3C XML
Schema language”. Two things to combine it with: XSD + XQuery; XSD
+ application/domain-specific languages. (Of course you can put
XQuery into an appinfo, but you might prefer to put it in a separate
document.) Second example: combining XSD with application-specific
NRL is a language that describes how to validate a multi-namespace
identifies groups of elements and attributes based on
specifies what schema to validate each group with.
It's a ‘combinator’ schema language. There
are ‘atomic’ schema languages; NRL combines atomic
Related work: Relax Namespace, Modular Namespaces (MNS), Namespace
Switchboard, DSDL Part 4 (ISO/IEC 19757-4).
The NRL data model distinguishes parent/child relations within and
between namespaces. [Long, very very detailed discussion of how to
cut the document into sections, following the simple rule: an element
is a section root if and only if it does not have the same namespace
as its parent. I don't understand why this took more than half a
On the whole, I thought NRL looked like a very clean, very
approachable solution to a problem I don't believe I have, and which I
have never noticed anyone else having in practice either. I may be
wrong on this: later on, Norm Walsh said it doess solve
a problem he has (and that I have, too), but he didn't manage to
persuade me, only to shake my conviction.
2.7. Town hall on XML validation
I missed the beginning, but the discussion was fairly interesting.
2.8. Ogievetsky and Sperberg, Book Builders: Content repurposing with topic maps
I didn't hear much on the publishing side at this conference, but
the co-author is my brother, so I took the opportunity to go to this
one. The basic idea was to make it easier to re-factor, re-organize,
and repackage existing information in a publisher's back list. (One
round of authoring, copy-editing, proof-reading, multiple saleable
W3C had a booth, and I enjoyed hanging around while the exhibits
were open. After the presentation of the XML Cup on Wednesday, we
displayed it at the booth, which gave me the pleasant feeling that my
teammates were proud of me.
Among the demos at the booth I saw and liked was one by David Ezell
of the National Association of Convenience Stores (and the XML Schema
Working Group), who demonstrated how he can (a) extract XML-encoded
transaction logs and summaries from a point-of-sale device using the
built-in Web server, (b) massage them a bit with standard XML tools,
and (c) dump them into Excel so that the accountants and business
analysts can work with the data.
Network Inference was showing an OWL-based inference engine at our
booth, which was simultaneously exciting and depressing: it looks
very cool, and it means I am going to have to learn OWL after all.
I also saw a demo of Infopath from Microsoft, which seems to be
fairly slick software. I wish it supported open standards instead of
being poised to compete with them, but leaving that aside I have to
say the software itself looked pretty cool.
Other booths were also showing some interesting stuff. Ontopia's
topic-map tools continue to look good, and I took a quiet moment to go
to their booth and look at an extended demo of them. I keep telling
them they should be W3C members; I hope they mean it when they say
they are thinking about it.
A small German startup called Infinity Loop was showing an
interesting pair of tools. Like many other tools, they focus on the
task of getting XML out of Word (and back into Word), but they take a
different approach. Instead of providing an inevitably complicated
tool for defining mappings between Word and an arbitrary target
vocabulary, they expect the movement of data from Word to the target
vocabulary to be a two-step (or n-step) process. Their
translator studies the layout of the Word document and produces XML in
one fixed vocabulary which captures a more or less generic logical
structure, with style information captured and placed in separate CSS
stylesheets. To get from their vocabulary to the target one, the user
will use XSLT or another tool of the user's choice. The result is a
little less obviously appealing than some mapping tools, but the
reasoning seems sound to me: mapping tools are notoriously difficult
to use, because the problem is so complex. The division of labor
implicit in the Infinity Loop product means the key step of the
process is done using standard tools for XML-to-XML transformation
(i.e. the tools programmers are going to spending a lot of time with,
anyway) rather than with a specialized conversion tool. Since I don't
do a lot of conversion work, my opinion on this may be misguided. But
I find the clarity of approach here attractive.
Along the way, other things also happened: I heard
thought-provoking talks from Jacek Ambrosiak, Adam Bosworth, and
Matthew Fuchs (among others) which I haven't tried to characterize
above. And along the way, the XML 2003 Program Committee awarded me
(along with Adam Bosworth) the XML Cup, which was welcome recognition
of the way I've spent my time over the last few years. The work
thus recognized, however, is by no means mine alone: it is the
common effort of members of W3C working groups and interest
groups inside and outside the XML Activity, of implementors, of
users, and of many others. It is to their work that the success
of XML must be attributed, and it was on their behalf that I
accepted the award.
And, since in large part the readers of this piece will be
those who have contributed, in one way or another, to the success
of XML, I can close this by saying to you directly, dear reader,
Thank you very much.