[
Lists Home |
Date Index |
Thread Index
]
peter murray-rust said:
> At 23:57 22/07/2006, Michael Kay wrote:
>
>>Since about 1993 there has never been a window of time in which new
>> technologies could be rapidly adopted client-side; it has always been
>> necessary to wait a few years until a significant proportion of the
>> installed base of browsers supported the technology in question.
>
> I have been following this discussion with a mixture of pessimism and
> optimism. I have thought carefully over the last few days and come
> exactly to Michael's conclusion. I want to ask whether this list - in
> the spirit of SAX and other developments can actually *do*
> something about it.
>
> When Henry Rzepa and I set up this list - in 1997 - our personal
> agenda was to see XML developed for communal vocabularies that can be
> shared between machines and humans. It now has that potential, but this
> discussion has shown it hasn't taken place in many disciplines. If you
> look back to XML-DEV archives you will see many similar
> discussions back any time after 1998 where we were discussing "the
> killer app for the web". I confidently predicted - I think in 1999 -
> would be that initial killer app.
>
> We have been continually destroyed and undermined by the browser
> manufacturers - including Firefox - which have failed to give us any
> stability on the client side. We have built many systems including
> CMLRSS, Java applets, Javascript, etc. only to see each new "browser
> upgrade" stop them working.
Just in a recent STM conference (2005 October, Frankfurt) you said that
fiasco of CML, MathML, and others XMLs was because publishers are not
really interested in those issues because economical stuff. They just want
follow with their "traditional" model of bussines.
Now you appear to claim that the problem becomes from browsers developers.
I never read you claiming that problem of lack of adoption of some XML
technologies becomes from the own XML world. Do you think that MathML,
STMML, XSLT, CML and the rest are good enough and the problem of adoption
becomes from browsers and publishers alone?
This remember me some MathML folks blaming browsers developers because
lack for native support for MathML and the subsequent lack of spreading
over the internet. I never heard one of those folks blaiming against the
desing of the own MathML as main cause for ugliness.
From the 2004 NSF / NSDL Workshop on Scientific Markup Languages Workshop
Report celebrated on Virginia:
<blockquote>
MathML is still seen as somewhat experimental by many potential users in
the math community.
</blockquote>
<blockquote>
MathML is therefore recognized as inherently incomplete. The authors of
MathML have explicitly targeted it for the expression of mathematical
content up through the early undergraduate level (first-order calculus).
Its utility for research mathematics, even with its explicit built-in
extension mechanisms (e.g., as exploited in the EU funded OpenMath
project), is still uncertain.
</blockquote>
<blockquote>
MathML is also intentionally bimodal, containing sets of elements to
describe separately the presentation of mathematics and the semantics of
mathematics. Generally, early implementers have focused on one or the
other but not both parts of the ML, resulting in asymmetrical
implementations that don't always interoperate as well as might be
desired.
</blockquote>
<blockquote>
The utility of MathML to enhance searching and improve accessibility of
online mathematical content has not yet been proven.
</blockquote>
<blockquote>
Searching of mathematically laden content by the mathematics it contains
is a complex issue. It's not altogether clear whether the level of
description implicit in content (semantic) and/or presentational MathML is
sufficient to support robust searching on the mathematics contained in a
resource.
</blockquote>
<blockquote>
It's also not yet certain that readers and other accessibility tools will
be able to exploit MathML effectively to make the mathematics embedded in
a resource more accessible, though that seems a safer bet.
</blockquote>
<blockquote>
While MathML is being adopted (at least experimentally) behind the scenes
-- e.g., as an exchange format for interoperation between applications
like Mathematica and Maple and in the editorial workflow of scholarly
journals, it has not been widely adopted by the authors of educational and
scholarly mathematical content. Research mathematicians continue to rely
heavily on TeX, which though exclusively presentation oriented (really a
specialized language for the typesetting of mathematics) is firmly
entrenched. Educators continue to rely on cruder technologies (e.g.,
embedding mathematics as static images within HTML or presentation only
markup within PDF documents) or exploit proprietary solutions such as
Mathematica workbooks.
</blockquote>
Have you thought that _maybe_ publishers and browser developers remain
unconvinced of capabilities of MathML and this is the main reason for the
spreaded ignoring? Do not forget also the technical difficulties for the
implementation of MathML in browsers.
> I take CML as an example. CML. CML is just for elementary chemistry then
> journals continue using old specific files for chemical information;
> "CML is just for elementary chemistry" as stated on this list- is
> totally incorrect. CML is designed for cutting edge chemistry.
Well, the concept of elementary is author and even community dependant -I
never saw a RHS (I. Prigogine) description of a molecular system on CML,
just elementary quantum mechanics for instance. But on any case the
choosing of the word was unfortunate.
In your personal comunication from 13 Feb 2006 you defined CML like:
<blockquote>
Chemical Markup Language is aimed at supporting a core of conventional
chemistry, much of it based on 19th century science.
</blockquote>
I remark this because in this list it was claimed that part of the
rejection of certain XML applications was because XML approaches were too
complete and people would prefer reduced and simpler approaches. Well, CML
is not a complete language for chemists or chemical physicists, therefore
generalized ignoring is not because CML was too complete...
> However
> what we really want is to ship CML, not SVG over the web because then
> the client has the semantics. We just can't
Is not this just a problem of XML? When I wrote
<h3>CML is a XML application</h3>
my browser "understands" the "semantics". When other writes
<section-title level="3">CML is a XML application</section-title>
my browser does not "understand". Maybe the problem is not the
presentational SVG, maybe the problem is that my browser cannot
"understand" your code if does not support CML code. I see no problem for
native support of one or two MLs, but it would be very difficult the
development of a browser understanding 100 or 200 specific XML languages,
and the development of specific browsers is so crazy like specific office
applications.
> The real problem is that we need to provide 1 million lines of Java
> code to the "client". We have these million lines - CML is not a toy.
And another million for physics and another for math and another for
biology...
>
> Peter Murray-Rust
> Unilever Centre for Molecular Sciences Informatics
> University of Cambridge,
> Lensfield Road, Cambridge CB2 1EW, UK
> +44-1223-763069
>
Juan R.
Center for CANONICAL |SCIENCE)
|
