Cart
[Home] [By Thread] [By Date] [Recent Entries]
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)
|
