[
Lists Home |
Date Index |
Thread Index
]
At 12:03 24/07/2006, Rick Jelliffe wrote:
Thanks very much Rick,
>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.
I agree with this rather pessimistic analysis. And there is no sign
of it being changed by the big boys. Given the pace of the Web it is
somewhat surprising that it has lasted for 10 years.
>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.
Thanks very much for this. A small number of people thinking in the
same direction is the main thing.
> 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?
That is what I favour at present, but I have brought this to XML-DEV
to see if I should change my views.
> 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?)
Personally I'm not keen on committee-based approaches - I prefer that
(as with SAX) we show the way and then get others to follow. In the
scheme of Web things it's a very cheap approach (albeit expensive for
the few involved).
>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?
Yes. Whether it should be another "browser" is unclear. The primary
goal is a common platform with plugins (or whatever terminology is
used) and a very lightweight distribution method.
My only constraint is that the solution should allow Java to be run -
our community is built that way. But it could be wrapped or scripted
in something else. (We also have to use C++ code from other sources
and currently wrap that with JNI).
>P.
Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069
|
