Please note, this is my personal observation, effectively made as a
well-informed outsideer (sine while I do read this list I don't make W3C
policy).
On Sun, 12 Sep 2004 16:38:30 +0100 (BST), David Woolley
<david@djwhome.demon.co.uk> wrote:
>
>> that they all have their rightful place, and there is no redundancy
>> happening as a consequence of simple ignorance of the left hand not
>> being aware of the right hand.
I don't think this is a practical appraoch to building a system on the
scale of the Web. I would offer as evidence the various systems which are
much cleaner in design (that is, don't have redundancies and overlapping
developments), such as Xanadu or hypercard and their relative lack of
acceptance on a global scale. I explaiin below how i think W3C manages to
address the problem that its pragmatic approach can allow...
> My impression is that SVG, at least, is trying to go it alone, with the
> result that it is busily competing with Flash at the same time that there
> is still no usable way of including simple vector diagrams on universal
> web pages.
This paticular example is a bad one. about 5 years ago HTML became XHTML
[1](XHTML 1.0 was published on 26 January 2000 as a Recommendation, but
obviously the basis was available before that as working drafts). SVG was
published about 18 months later later as a Recommendation [2], but was
pretty much the same as the 1999 drafts [3] (certainly for basic vector
grtaphics). The point of doing these things in XML was to work towards
being able to include them in each other. SVG got pretty close pretty
quickly with the foreignObject element [4], which could specify a required
namespace - if you understood the namespace (such as xhtml's namespace)
then you would render the content. There was a cascade mechanism, so if
you didn't understand it, you could look for an alternative that you could
understand. (This is how object was designed in HTML around 1997...).
At this point there were tools that could mix the two together, but you
couldn't validate mixed HTML and SVG easily. Two solutions were provided
for that. The first is the possiblity to use XML Schema [5] (May 2001),
which allows slightly different validation to what is possible using DTDs.
The second came about through the work on mdularisation of the XHTML DTD
(first published as a Recommendation in April 2001 [6]). All well and
good, you could now write a DTD or schema that allowed you to validate
XHTML and SVG mixed together. (The same applies to MathML and XHTML by the
way, which was another common use case). You could mix them - in SVG's
case in Amaya or Xsmiles or DENG (I have never tried the SVG-enabled
Mozilla so don't know if it handles this or not), in MathML with Amaya or
Mozilla/Netscape or Internet Explorer (thanks to some nasty IE hacking
from IBM) or ... All that was missing was the actual DTD/Schema.
Thank you Masayasu Ishikawa for doing it [7] (in 20002). Amaya, for some
time now, has been able to produce verifiably valid mixed SVG, XHTML and
MathML with a wysiwyg interface. The basics were demonstrated in 1999
(then using a slightly different vector graphics language), and the idea
was not new. But standardisation is very slow work.
There is another piece to the puzzle - it's all well and good to have SVG
and MathML mix with HTML, but what if I want to add ChemML? or a music
language? (The one I wrote is called CAML - there are a number of others
around). Or some other specialized markup language?
In 2001 the W3C first published work on how to handle compound documents
in general [8]. It turns out that if it isn't impossible, it does require
substnatial amounts of work - standardised interfaces that pass quite a
lot of information, and it quite possibly means that no tool can expect to
be "The" browser. This work does continue, albeit almost imperceptibly at
times.
>> developed in ignorance of another already available technology which are
>> themselves designed to deliver what these others are also trying to
>> address?
>
> It almost certainly is doing this. This seems to be the fate of all
> technological standards. Often some feature gets addressed at a low
> level and layers of abstraction get added. As the abstraction adds,
> users
> insist that they can't understand the details, so the low levels get
> forgotten. Eventually someone re-invents the requirement and layers a
> solution on top of the current abstraction level, even though there is
> support at a lower level. (This sort of cycle also occurs in marketing,
> in that after a few years you can re-market old concepts as new, just
> by using a new name.)
The mathematics of this is obvious. If 10 people spend 10% of their time
following the development of a new technology, and 5% of their time
dealing with administrative things like paying taxes and publishing
minutes, and 30% of their time sleeping, and 10% of their time having fun,
then in order to make sure they know what the other 9 people are doing
they have to follow 9 new technologies in 45% of their time. Given that we
assume it takes someone 10% of their time to actually follow the
development, it's pretty clear that a bunch of the development is just
going to pass them by.
Actually W3C develops a lot more than 10 different things, and while most
staff members can track 4 or 5 reasonably closely, nobody can follow the
details of all of them if the work is to proceed at the pace of
development. So ther eis a process that provides for continuous review,
for harmonisation, and "reintegration". This can be seen, for example, in
the development of Xpath, XSLT, and XQuery, which merged together the
things they had in common as they developed (in some cases at version 2),
or in the re-use SVG made of work from SMIL and CSS, or in other examples.
Sometimes it happens before a spec is published. Sometimes there is
resistance in a developer community to things "not invented here" (note
that there are a number of languages to write schemas for XML, several
syntaxes for RDF, and various varieties of HTML in common use) - and if
that is the case on both "sides" of a particular redundancy the choice is
either to stop all development until everyone agrees (which is not always
practical) or let it go along, and work to bring the developments together
as it becomes possible.
> Although not standardised, you can see this in email signatures. A lot
> of the RFC 822 headers carry information that people now put in
> signatures,
> but people first started suppressing headers because they thought them
> too noisy, then started treating them as technical mysteries, even though
> they are actually designed to look like the headings on a military
> memo.
This is a good example of how the real world works. If military memos were
an ideal way of carrying information for all purposes, we would still use
email headers and not signatures. But it turns out they are not. So they
are used "silently" to carry a lot of important semantic information that
can be processed by email programs, and signatures are used to carry
human-readable versions. (There are parallels here with HTML's head
section, and the use of rich media in the presentation of a document - if
we take away the possiblity to use multimedia, somehow, in HTML documents,
it would die as a format more or less immediately.
[1]http://www.w3.org/TR/2000/REC-xhtml1-20000126
[2]http://www.w3.org/TR/2001/REC-SVG-20010904
[3]e.g. http://www.w3.org/1999/08/WD-SVG-19990812/
[4]http://www.w3.org/TR/SVG/extend.html#ForeignObjectElement
[5]http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/
[6]http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/
[7]http://www.w3.org/TR/XHTMLplusMathMLplusSVG/
[8]http://www.w3.org/TR/2001/NOTE-CX-20011211
Hope this is worth 2 cents, Geoff :-)
cheers
Chaals
--
Charles McCathieNevile charles@sidar.org
Fundación Sidar http://www.sidar.org