[
Lists Home |
Date Index |
Thread Index
]
At 10:29 24/07/2006, juanrgonzaleza@canonicalscience.com wrote:
Thanks
I will reply in this thread as it is pertinent to XML on the Web...
If it gets too offtopic we should discuss it elsewhere...
>peter murray-rust said:
> > At 23:57 22/07/2006, Michael Kay wrote:
> >
> >
> > 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.
I did not refer to the "fiasco of CML, MathML, and others XMLs". I do
not (unsurprisingly regard CML or MathML as fiascoes) :-)
The concern that I had at that time was the availability of
scientific data in *any* form. The main concern was about Open Access
and Open Data.
In fact a lot has happened in the last 9 months and many publishers I
speak to are much more enthusiastic about Open content *and*
publishing in XML. I believe that scientific publishing may, indeed,
become the first real application of community-driven XML over the visible web.
>Now you appear to claim that the problem becomes from browsers developers.
Yes
>I never read you claiming that problem of lack of adoption of some XML
>technologies becomes from the own XML world.
That is because I had not identified the problem clearly until a few
days ago. Now, especially after reading XML-DEV I agree exactly with
what Michael Kay says. Things continue to move fast and I am able to
update my viewpoint :-)
>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?
No - it is a complex problem. I am not fully competent to comment on
MathML but I believe it to be the right way forward - compared say to
embedding proprietary formats such as Mathematica. But I think the
basics of CML are now fairly solid and can support much of the
chemical content in a peer-reviewed primary publication. Perhaps at
the 80/20 level. So not "fully complete" - that will be never - but
yes, "good enough" for many purposes.
>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:
Which I attended and presented at.
><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>
I agree with this analysis. However maths is not chemistry and the
philosophy shown above does not translate. There are many differences
including (a) math has its own pioneering markup (TeX) which serves
much of what is required (b) relatively few mathematicians need to do
symbolic processing of maths (c) maths is not data-rich in the same
way as chemistry.
>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 do not forget them! Many of the difficulties apply to CML as well.
> > 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.
That is correct. There are complex systems that cannot be described.
But for mainstream journals like J. Org. Chem (synthesis), Dalton
(crystal structures), TheoChem (computational chemistry) CML can
cover a great deal. And we now have ca. 10 codes fully CMLised using
a Fortran-based DOM (FoX) - a tribute to those authors Toby White,
Jon Wakelin and Alberto Garcia.
> 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>
True
>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...
The message was actually that because much mainstream chemistry has
not basically changed for a century, then markup languages are likely
to be stable and meet a real need. In contrast Physics (where I spoke
at the German Physical Soc earlier this year) require a completely
different approach to markup.
> > 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?
Yes. That is what much of this thread is about
> 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.
That is absolutely correct. I am trying to get my code to your
browser. Or, maybe a better solution than a browser.
> 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.
Agreed. I am not expecting browsers to support CML. What I *am*
asking for is client-side functionality.
> > 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...
Yes. Biology has much more - and it manages very well. That is
because many users are capable of installing Open application
software. This is still a problem in chemistry.
HTH
P.
Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069
|
