OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] [SUMMARY #1] Why is there little usage of XML on the 'visi

[ Lists Home | Date Index | Thread Index ]

peter murray-rust said:
> 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.

Well i was refering to the fiasco to visible CML, MathML.... Your thought
were then that publishers have failed to adapt to the web, internet and
ICT in general and that publishers need to getaway from their fixation on
PDF and GIFF -basically my point here people prefer PDF, GIFFs over XML
formats as XSL-FO, SVG...-, and move to XML, MathML, CML, etc.

You said most publishers are not interested in these issues because they
do not fit into their business model and stated the need for a new
‘Agenda’ for the sciences.

You also said that the web is bigger than the publishing community and
that. if the latter doesn’t change, the new developments will happen
anyway and leave them high anddry.

Now you target may be over broswer developers and maybe you think

<hypotetical>
XML community is bigger than the browsers community and if the latter
doesn’t change, the new developments (CLAX) will happen anyway and leave
them high anddry.
</hypotetical>

> 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.

Yes, i can see Elsevier using p-MathML for publishing and being
(over)entusiastic about future of XML on the web. I can also see ACS
recommendations about content MathML encoding. Well i wait was not a
fiasco but i doubt success of so one initiative. I have revised several of
those entusiastic evaluations of technology. I wonder how many at the ACS
recommending mathml know that compositionality is.

>
>>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 :-)

I was not saying that.

>>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.

Therefore you are not fully competent but entusiastically recommend
usage/support of MathML (and others MLs) in your writtings and talks about
STM. Interesting!

The comparison with propietary formats is off-topic.

> 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.

Let me take like true your 80/20 and evaluation of CML. What for the
remaining 20? A new CML-2 language? a new browser? 10^8 new lines? The new
CML-2 could be unified with current one? Would coexists? What about costs?
What is the cost of CML in current workflows 20% more? What are the
benefits?

I would be happy if you explain my how would i encode a Redfield equation
for a physicochemical system of interest in CML. After all electron
transfer reactions or of interest for chemistry ;-)

>
>>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.

Well, (a) TeX is for typesseting not for content, search, or accesibility.
Most of above criticism address to the semantic part of MathML (b)
mathematicians, physicists or enginners, what is the difference?
Alternatives are being proposed: OpenMath, semantic LaTeX, LISP...
Completely agree with (c).

>>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 know developers are interested in on-line math but are not interested in
MathML. Therefore failure to spreading support of XML-based math in the
visible web is not because browers...

I am a big fan of content oriented web and did a big efforts to provide a
website in that way but never worked.

>> > 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.

And is nice, but then we become to the quid of the whole question with the
XML technology, if MathML, XHTML, SVG, and CML are not fulfilling the
needs of a big part of the community very interested in this stuff. That
community is obligated to develop alternatives solving every day problems
and then what would browsers and publishers do: what standard would they
natively support or encourage? Why would CML be prefered over another
chemical approach? Or why CanonMath over MathML would gain support in
browsers?

>>  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.

Yes, i agree about chemistry, but maybe it is time for a change. For
instance chemical reactions rates are usually modelled in the traditional
way as R = k[A][B] whereas concepts of atoms and bonds are mainly
19th-based for most chemical thinking. The question is what for
topological and informational theoretic atoms? What for Keizer rate laws R
= Omega exp[-nF/k]? In those cases CML is of no interest for some of us.

People working with computational software in those fields do not use CML
for storing, transformation interchange of information. I remark this
because very often one heard (not from you of course) that CML is XML
_for_ chemistry without further remarks on what is covered and what is
not.

This discussion is applicable to other MLs. People is using/promiting
canvas for taks that SVG is not adequate; OpenMath or HTML-Math for tasks
are not well covered by MathML, etc.

>
>> > 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.

I find this exciting.

>
>> > 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
>

Juan R.

Center for CANONICAL |SCIENCE)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS