Two quick thoughts.
Somehow I think we are, or should be, talking about a lot more than a
document language. I'd prefer "Extended Modeling Language" as one
Secondly, I don't think even a series of specific fixes will get is there -
wherever there is. Nor will focusing on a particular set of domains,
although it will illustrate directions that are needed. A proper fix
to the foundations, which, for instance, allows for extensions that
will meet compatibility goals, should easily encompass all
these. Even the less popular approaches, that have evolved indicate
the incredible power of a good modeling language.
To summarize,although this is hard in these short posts - I
think the solution is architecture rather than specific fixes and
capabilities. But I do sympathize with a sad history for XML 2.0 and other
tschotskes, and maybe a Balisage is indeed needed.
That, off my chest, I think that, with a separation of syntax (i.e. syntax
variations to support a broad variety of data representations that
produce infosets) and semantics (based on infosets as objects), there
is a very credible base for a unified foundation as suggested by Kurt - and
that this can allow for a considerable degree of compatibility with what
The other crying foundation requirement is for simple and comprehensive
approaches to modularization that allow small specifications to work
naturally together in a variety of ways. And, with the freedom
to inovate, this should fall out of any unification effort.
In a message dated 12/4/2010 12:37:09 P.M. Eastern Standard Time,
I'm not sure about that. What I find significant here is that for
the first time there is a new meme here that I haven't heard really discussed
Is it time to create a new stack?
Nobody is arguing for a new extension of XML, an XML 2.0. Been
there, done that, got the tschotskes. Nobody is defending XML as being
superior to JSON, only that they accomplish different needs, and that we need
to decide whether or not its worth breaking new ground. I'd argue the same
issues are occurring in the Semantic Web world, where XML/RDF has been
increasingly relegated to an unwieldy alternative format.
In a way its a lot like the unification of forces in physics -
you can't realize that electricity and magnetism are manifestations of the
same force until you have several years of empirical data and a large enough
base, you can't realize that electro-magnetism and the weak force are
themselves unified at higher levels and that the weak force and the strong
force are simply different symmetry breakings of a unified model. We're facing
that now with data structures, and the realization that JSON and XML are
different manifestations of a larger need to provide a compelling unification,
and that the form of either by themselves are not as important as the fact
that at some stage we can recognize that there is a need to see both as part
of a more comprehensive data modeling model. This is one of the reasons I
think the NoSQL movement is now gaining steam.
The issue, as you put it, is what to do about it. SGML really
isn't the answer - it solved certain early document needs, but was ill-suited
as a format for data modeling. XML proved that you could strip out a great
deal of SGML and actually end up with a more flexible, functional language.
The drivers for unification are there; we're seeing more and more bridges
between formats, which to me usually precedes a realization that we've reached
a higher level of abstraction and are trying to patch it together with lower
level tools - eventually you have to embrace that abstraction and find a way
to more properly express it to get combinatorial explosions under
Perhaps Unification should be the focus of an IWC conference, or
Balisage or one of the other markup symposia. Don't call it XML, call it
something like DON - Document Object Notation. Throw out all initial
assumptions about specific object notations and focus on infosets and modeling
mechanisms for infosets. Recognize that each of the three domains - JSON, XML,
RDF - are all valid in their need to accomplish specific tasks, but question
whether there is some underlying consistent system that can encapsulate all
this information easily and readily. Keep the working group small and focused,
and put the thought leaders for each camp as at least some of the
representatives. It may be that there is no benefit to such unification, that
we're better with three standards rather than one, but its worth making the
effort to at least try to find common ground.
Lockheed / US National Archives
On Sat, Dec 4, 2010 at 11:39 AM, Dimitre
I am watching this and other threads with
Because we have often been presented with ideas,
some of them good, to
This discussion is no different than the previous ones --
outcome that didn't and will not happen.
What I want to see
is not a complete, grandiose plan then a Big Bang
to produce it -- the
Big Bang may have happened only once and nobody
has actually seen
What I want to see is *starting* with the implementation of
steps at a time, of just one first step -- beyond
The critical missing part in this discussion is how to
good ideas that have surfaced.
Is it possible to
have individual(s) that would implement series of
improvements? Improvements that would quickly gain
critical mass of users
to become de-facto standards?
Because if not, all the talks are
stirring deep waters with a teaspoon.
Here is my
As a start, take one obvious improvement, implement it for
Then go on with the next one.
But just stop only
The big problem is that something more than talking *has* to
To be specific, as a first step produce XML-N1 where the
namespace is abolished. Something not so difficult and
that eliminates 40% of the questions we see in forums. So
will be saved, satisfaction increased, trust and acceptance
*Now*, this is something.
Then face in turn XML-N2 -->
XML-N3 -->... XML-Nk...
Most important, stop talking and get
started, then never stop while
Truly great madness
cannot be achieved without significant
To invent, you
need a good imagination and a pile of
Never fight an inanimate
You've achieved success
in your field when you don't know whether what
you're doing is work or