It's time for practical XML!

[Peter Murray-Rust]

At 23:27 03/10/98 +1000, James Robertson wrote:
>Hi all,
>
>I've just finished another couple of hours
>wading through XML-DEV and XML-L, and I
>confess my frustration has overtaken me.

I understand this. I have been trying to develop this list as somewhere
where things actually happen. We've had some success.  But the successes
rest on a great deal of *necessary* discussion. For example, in the
discussion of how we build objects from elements it is clear that there is
lightly explored territory with some very good contributions. There are
different ways of doing things and some may be preferable to others - this
will only emerge after the discussion.

The history of SAX is an example. There were about 2 early forays into this
field, which revealed it was important to do something and laid some
groundwork. They then went fallow (a positive word) and finally David
Megginson conducted XML-DEV during Dec 1997. It looked like it would take a
month - and the first part did. But then there was the hard graft over ca.
3 more months while the details were ironed out. I would contend that the
process per see could not be easily bettered.

The same thing has happened - over a more gradual timescale with XSchema.
Something is clearly needed in this area - whether XSchema is 'it', only
time will tell. At present it looks like being the first offering in this
field and over 50 people (I think) have contributed to the discussion.

There is clearly a very great need for something similar for
objects/elements. We are at an early concept stage. There are many
different views of the way that elements might be transformed into objects.
For many applications (e.g. technical, non-textual) this is *the* most
powerful and critical part of XML. For example MathML and CML will rely on
structured objects if there is to be re-use (rather than rendering) and we
cannot proceed confidently until it's solved.
>
[...]
>
>It's time to stop writing standards.
>I don't want to know about any more
>*ML languages, however elegant they
>are. We are now at the stage where
>new standards are being submitted
>faster than old ones are being finalised.

I think we should distinguish between extensions to the functionality of
XML and markup languages based on XML. The extensions to the functionality
are horizontal such as XLink, XPointer, RDF, DCD/XSchema, XSL, etc. They
may be a fundamental part of new markup languages. For example, my own
contributions - CML and the Virtual HyperGlossary both rely on XLink to
provide powerful data structure. *My* frustration is the XLink (and
XPointer) are still not Recommendations. And I cannot expect people to
build robust commercial tools until  these specs are dry.
>
>Now I know it is a lot more fun to
>talk about the next gee-wiz solutions
>to the world's problems, but we all
>need to get stuck into some hard work.

I agree. I sometimes think that the discussion on XML-DEV is too far
removed from implementation, but I haven't intervened. Many of the
contributors also help create tools, demos, resources, etc. For example,
the discussion on names may seem abstract, but people like Eliot Kimber
have contributed greatly with implementations as well (e.g. PHyLIS - if
have the caps right). Most of the regulars on this list work very hard at
collaborative contributions - it may not always show above the surface.

>
>A lot of people seem to be trying to
>hit every target with XML, and most are
>talking about "finding the killer app".
>
>XML does not need a killer app. It is
>not a solution unto itself. It is a 
>handy tool for doing real-world work.
>
>I have not participated in these discussions
>on the whole, because I have been too busy
>implmeneting SGML in the workplace, using
>standard languages and off-the-shelf tools.

Fine :-) and I hope you will implement XML when the tools are available for
your purposes. Part of this list's traffic is coordinating the development
of those tools. SGML had a lack of cheap tools and there was often little
interoperability. So it led to good in-house solutions but poor WWW
provision. XML is designed to be used over the wire and aspects of that are
hard. As someone who has written some of the tools, even getting them
distributed easily isn't easy. And interoperability is impossible without
public discussion.
>
>I want to be able to do the same with XML.
>
>What we all need is:
>
>* rock-solid XML parsers for every platform
>  under the sun, especially business development
>  tools like: Visual Basic, Delphi, Powerbuilder,
>  etc.

We have rock-solid parsers. We have a rock solid event-based API (SAX) and
we have a rock-solid Object model (DOM). We desperately need the next layer
on top of the DOM for may *ML applications.


>* Embedded XML editors for use in business-specific
>  applications. These need to be ActiveX controls,
>  Delphi VCLs and the like.

XML editors are *hard*. They require substantial investment. If they are to
be syntactically (DTD) and semantically (Schema) driven we must have
agreement on those. That's why XSchema and related efforts are so
important. For example, I have written a forms-based editor for JUMBO.
Works. *But* it is based on my own data types. It *has* to be, because
no-one agrees on how to send a floating point number using XML. We shall,
sometime. I'm frustrated by the lack of specs here :-)

>
>* Thousands of handy little tools that run without
>  virtual machines, or other overhead, with simple
>  interfaces, that make handling XML easy.

They will not interoperate unless we have standards. Can I create an XML
document with software X and send it to someone with software Y? Only if we
agree on what is to be sent. There are a number of ways of agreeing:
	- everyone buys their toolkit from a single vendor. This can work, but it
doesn't encourage innovation
	- a small number of toolkits evolve independently. This tends to lead to
islands of interoperability. But it's awful for me. Let us assume that
Netscape and MSIE expose different object models. Then to send a molecule
from X to Y I have to write CML software for *each* browser. And when
coins/XXX/SUN/XML4J all expose different interfaces the chemical community
has the same babel as it has now (except that that is based on Fortran).
Also semi-closed interfaces like this make it very difficult to develop
semantic interoperability.
	- we discuss the problem openly and converge towards solutions where
possible. XML is a prime example of this. There *was* a starting point
(SGML) and it took 100+ people + many more contributors 1.5 years and 10000
e-mails to get to the current Rec. Namespaces took 2000 e-mails.

We are attempting something that has never been done before - the creation
of objects on one machine that must be semantically interoperable on
another machine (after transmission in serialised form). The two clients
have had no previous negotiation. [That, in part, is a reason why the name
debate is so passionate and runs and runs - we have very little global
experience of identifying machine-readable objects by universal names other
than *.html documents].
>
>Most of these solutions need to be commercial,
>with support, documentation, upgrade plans,
>bug-fix releases. Business will not use unsupported
>freeware, and they _will_ pay for the tools they
>need.

I won't challenge this - even though I am an OpenSource fan and think that
the Linux model is extensible to XML. [And many contributions on this list
are top-quality OpenSource with no evidence that they are unsupportable.]
My prediction is that over the next 2-3 months we shall see lots of first
version XML tools from vendors - many, but not all, with SGML backgrounds.
I suspect that there will be little effective interoperability between
these tools except at syntactic level - they will emit WF XML, but beyond
that they will give little support for managing documents produced by
others. Maybe this is a necessary phase. I hope we can move past it. I am
still in favour of a diversity of suppliers and applications but I hope we
can work towards having semantic interoperability
>
>There are a lot of _exceedingly_ good developers
>on this list.
>
>To them I say: Please, please, stop writing new
>specs, and help us all by writing real apps.

I think a lot *are* writing apps. I think also, that they desperately need
specs to write these apps. My own experience is that I can develop
something about 5 times faster if I have a spec to work to rather than
working it out for myself. In the latter case there is:
	- the worry that you aren't going in the right direction
	- no one to turn to for help
	- no interoperability.
etc.
So when XLink, XSchema, XPointer, SOAPI (or whatever we call it) are
frozen, people will develop apps much more rapidly.

BTW - if you would like to help speed the process up we would be delighted :-)


	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)