[
Lists Home |
Date Index |
Thread Index
]
juanrgonzaleza@canonicalscience.com wrote:
> peter murray-rust said:
>
>> 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.
>>
> 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?
> ...
> 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 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.
>
Obviously XML is capable of representing the information. (Almost any
syntax can.) Obviously modeling more than toy versions of human
technologies (typesetting, mathematics, chemistry) is not trivial.
Obviously there are tradeoffs, and deciding to make some things easy may
in fact make other things hard. And, most obviously, when people master
an existing tool, they can be loathe to adopt another. Consequently
there will always be people who aren't served optimally or adequately by
any single standard. That is why plurality is important. That a
technology is not perfect just means it is a human technology.
I'm with Peter, in that I had expected there would be more of a
profusion of domain-specific browsers. I think Microsoft managed to
stuff that up, with their Java-busting J++ shennanigans; and IBM has put
the nail in the coffin with SWT. Sun also abandoned their Hot Java
browser development, so they missed the opportunity to provide a
cross-platform browser host based on pure Java. Thanks boys. In the
recent past, the browser makers hoped that XUL/XAML + JavaScript +
server-side smarts would be enough.
My company bases most of our products on a special kind of browser: it
accepts arbitrary XML (available in one pane as a tree or breadcrumb
bar) and applies custom renderers or XSLTs to the currently select
branch, displaying the results in another branch. All actions on nodes
in the XML are based on URLs. This is a really convenient architecture
for browsing. So there is scope note only for domain-specific browsers,
but also there are new kinds of generic XML browsers possible too.
I would be very interested in discussing strategies for this with Peter
etc. Is the answer, for example, for everyone who makes domain-specific
browser tools to band together and make a new open source framework; I'm
thinking of Java-based tools in particular? Or is the answer to get MS
and Mozilla and Opera et al to sit at a table and agree on a common
plug-in API? (And see whether MicroSoft's 12 Tenents are worth the paper
they can be printed on?) Or is it to make some new API that abstracts
out the safe parts from existing browser's plugin API? Or is it a
distribution problem: do we need to start thinking in terms of browser
distributions that are like Linux distributions: all optioned up from
the outset?
(By the way, Juan, answers based on replacing XML are best dealt with on
some other mail list.)
Cheers
Rick Jelliffe
|
